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Executive  Summary 


Responding  to  catastrophic  events,  man-made  or  natural,  places  tremendous 
demands  on  governmental  organizations  at  all  levels.  To  respond  as  efficiently 
and  effectively  as  possible,  these  organizations  must  determine  the  events,  or 
threats,  that  are  most  likely  to  occur  in  their  area  of  responsibility,  prioritize  the 
threats  based  on  their  predicted  impact,  and  determine  how  to  best  apply  their 
resources  to  mitigate,  and  prepare  for,  the  threats.  Because  each  threat’s  impact 
can  vary  depending  on  any  number  of  conditions,  multiple  scenarios  must  be 
considered  for  each  threat. 

The  Department  of  Homeland  Security  (DHS)  has  defined  15  National  Planning 
Scenarios,  along  with  a  Target  Capabilities  List,  which  describes  needed 
capabilities  related  to  the  four  homeland  security  mission  areas:  prevent,  protect, 
respond,  and  recover.  In  addition,  state  and  local  emergency  personnel  must  have 
plans  in  place  for  managing  emergencies  in  their  areas  of  responsibility. 

To  support  the  preparation  and  response  phases  at  the  state  and  local  levels, 
DHS’s  Directorate  for  Science  and  Technology  (DHS/S&T)  wants  to  provide  an 
integrated  suite  of  modeling  tools  to  state  and  local  emergency  planners  and  re¬ 
sponders.  The  challenge  is  to  provide  tools  that  can  be  used  by  both  well-funded 
jurisdictions  and  those  with  little  funding  and  little  or  no  information  technology 
support.  In  support  of  that  goal,  LMI  conducted  a  gap  analysis  to  identify  the 
models  and  other  tools  needed  by  a  broad  spectrum  of  emergency  services  (ES) 
stakeholders  for  preparation  and  response,  and  considering  the  results  of  the  gap 
analysis,  we  identified  both  functional  requirements  for  software  and  the  opera¬ 
tional  capabilities  needed  to  implement  and  support  that  software. 

The  functional  requirements  we  identified  are  high-level,  core  areas  of  functional¬ 
ity  that  the  ES  community  considers  necessary  in  any  model  or  tool  they  might 
use  to  prepare  for,  respond  to,  and  recover  from  an  emergency.  The  following 
functional  requirements  are  key: 

♦  Models  and  tools  to  support  modeling  for  the  15  National  Planning 
Scenarios  should  be  provided  to  all  jurisdictions  by  DHS. 
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♦  Models  and  supporting  tools  should  accept  inputs  from,  and  outputs  to, 
commonly  available  software  such  as  the  Microsoft  Office  suite  of  prod¬ 
ucts. 

♦  Jurisdictions  need  a  process  to  integrate  model  and  tool  use  into  everyday 
operations. 

♦  To  maintain  continuity  of  operations,  software  must  look  and  operate  the 
same,  regardless  of  mode:  networked,  local  area  network  only,  or  stand¬ 
alone  laptop. 

♦  Software  must  integrate  with  other  applications  easily,  scale  up,  and  use 
familiar  tenninology,  for  support  by  nontechnical  emergency  personnel. 

♦  Adoption  and  implementation  of  software  must  be  possible  for  both  well- 
funded  jurisdictions  and  jurisdictions  with  no  overhead  funds. 

♦  Maintenance  of  software  must  be  very  low  cost  and  require  minimal  tech¬ 
nical  skills  from  using  jurisdictions. 

♦  Asset  management  tools  must  exchange  data  using  some  common,  easy- 
to-use,  and  low-cost  or  no-cost  standard  or  format. 

♦  Software  must  include  more  than  the  technical  information  needed  to  im¬ 
plement  it.  Jurisdictions  need  infonnation  on  different  implementation 
paths  and  tools  (such  as  checklists)  to  help  them  plan  for,  deploy,  and  sup¬ 
port  software. 

♦  Jurisdictions  need  models  to  support  three  types  of  risk  analyses:  overall 
risk  assessments,  in-depth  analyses  of  high-risk  hazards  and  threats,  and 
analyses  of  low-probability/high-impact  threats. 

The  operational  requirements  we  identified  represent  barriers  that  hamper  the 
ability  of  almost  all  jurisdictions  to  adopt  new  models  and  tools,  although  the  im¬ 
pact  varies  depending  on  factors  such  as  location,  population,  executive  support, 
and  structure  and  size  of  the  ES  organization.  The  following  are  key  operational 
requirements: 

♦  Approaches  and  methods  to  easily  and  effectively  engage  all  planning  and 
general  information  sharing  across  all  disciplines 

♦  Guidance  at  the  federal,  Federal  Emergency  Management  Agency  region, 
state,  and  local  levels  on  data  and  infonnation  sharing 

♦  An  integrated  process  to  define  the  roles  of  the  disciplines,  the  key  respon¬ 
sibilities,  and  both  the  shared  and  the  role-specific  privileges  of  operations 
management  software 
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Executive  Summary 


♦  Decision  support  information  from  a  trusted  source  in  the  ES  community 

♦  An  authoritative  source  for  guidance  and  standards  in  effect  and  a  regular 
review  process  to  ensure  that  they  remain  viable  and  up  to  date 

♦  At  the  federal  level,  clear  differentiation  between  what  should  be  regarded 
as  “guidance”  and  what  constitutes  “standards” 

♦  Flexible,  adaptable,  and  changeable  processes  for  use  by  jurisdictions  dur¬ 
ing  both  preparation  for  and  response  to  an  event 

♦  Policies  that  support  collaborative  planning,  risk-based  funding,  and  proc¬ 
esses  or  methods  to  resolve  inter-jurisdictional  differences  of  opinion  and 
to  address  political  issues. 

DHS/S&T  needs  to  define  the  functional  requirements  in  more  detail  and  then 
identify  the  specific  technical  requirements  for  modeling,  simulation,  and  analy¬ 
sis.  DHS/S&T  also  needs  to  address  the  operational  requirements  within  its  pur¬ 
view.  However,  some  of  these  requirements  can  be  addressed  only  by  other 
organizations  within  DHS.  S&T  should  partner  with  those  organizations  to  ensure 
that  the  operational  requirements  are  fully  addressed.  These  partnerships  are  criti¬ 
cal,  because  some  operational  requirements  must  be  met  if  DHS  is  to  overcome 
the  barriers  to  the  adoption  of  modeling,  simulation,  and  analysis  tools  by  the  en¬ 
tire  ES  community. 
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Chapter  1 

Introduction 


Responding  to  catastrophic  events,  man-made  or  natural,  places  tremendous 
demands  on  governmental  organizations  at  all  levels.  To  respond  as  efficiently 
and  effectively  as  possible,  these  organizations  must  detennine  the  events,  or 
threats,  that  are  most  likely  to  occur  in  their  area  of 
responsibility,  prioritize  the  threats  based  on  their 
predicted  impact,  and  determine  how  to  best  apply 
their  resources  to  mitigate,  and  prepare  for,  the 
threats.  Because  each  threat’s  impact  can  vary 
depending  on  any  number  of  conditions,  multiple 
scenarios  must  be  considered  for  each  threat. 

The  Department  of  Homeland  Security  (DHS)  has 
defined  15  National  Planning  Scenarios  (NPSs),  along 
with  a  Target  Capabilities  List,  which  describes 
needed  capabilities  related  to  the  four  homeland 
security  mission  areas:  prevent,  protect,  respond,  and 
recover.  In  addition,  state  and  local  emergency  personnel  must  have  plans  in  place 
for  managing  emergencies  in  their  areas  of  responsibility. 

In  this  operational  requirements  document,  as  well  as  in  two  companion  docu¬ 
ments  (a  mission  needs  statement  and  a  concept  of  operations),  we  use  the  terms 
emergency  management  (EM)  and  emergency  services  (ES).  We  define  those 
terms  as  follows: 

♦  Emergency  management — organizations  charged  with  the  managerial 
function  of  creating  the  framework  within  which  communities  reduce  vul¬ 
nerability  to  hazards  and  cope  with  disasters.1  The  emergency  manage¬ 
ment  community  includes  local,  regional,  tribal,  and  national  agencies 
charged  with  maintaining  the  programmatic  framework,  managing  pro¬ 
gram  requirements,  and  administering  local  and  federal  funding. 

♦  Emergency  services — organizations  that  provide  for  public  safety  by  the 
delivery  of  services  such  as  law  enforcement,  firefighting,  emergency 
medical,  search  and  rescue,  and  the  like.  The  emergency  services  commu¬ 
nity  includes  all  the  emergency  services  providers/responders,  including 
EM  agencies. 

Emergency  management  is  often  described  as  having  a  life  cycle  with  specific 
phases.  The  three  most  commonly  recognized  phases  are  preparation,  response, 

1  FEMA’s  independent  study  course  IS230,  Principles  of  Emergency  Management. 


At-a-G  lance 


DHS/S&T  is  working  to  provide 
an  integrated  suite  of  modeling 
tools  to  state  and  local  emer¬ 
gency  planners  and  respond¬ 
ers.  The  ability  to  use  such 
tools  varies  greatly  among  the 
various  local  jurisdictions  and 
tribal  governments.  The  chal¬ 
lenge  is  to  produce  tools  that 
can  be  utilized  by  both  well- 
funded  jurisdictions  and  those 
with  less  funding  and  little  or 
no  IT  support. 
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and  recovery.  Other  categorizations  exist;  for  example,  the  Federal  Emergency 
Management  Agency  (FEMA)  website  mentions  prevention,  mitigation,  and  risk 
reduction,  but  these  activities  can  take  place  as  part  of  preparation  and  are  not 
phases,  per  se. 

To  support  the  preparation  and  response  phases  at  the  state,  local,  and  tribal  lev¬ 
els,  DHS’s  Directorate  for  Science  and  Technology  (DHS/S&T)  would  like  to 
develop  a  suite  of  models  and  other  tools  that  state,  local,  and  tribal  planners  can 
use  for  modeling,  simulation,  and  analysis  of  likely  threat  scenarios.  DHS/S&T’s 
focus  is  on  enabling  its  customers,  the  DHS  components,  and  the  components’ 
customers — including  federal,  state,  and  local  emergency  responders — to  achieve 
their  vital  mission  of  securing  the  nation.  DHS/S&T  also  emphasizes  that  the  im¬ 
plementation  of  such  technology  must  focus  on  its  use  as  a  support  “tool”  that  can 
augment,  but  does  not  in  any  way  replace,  essential  human  decision  making. 

DHS/S&T  tasked  LMI  with  conducting  a  gap  analysis  to  identify  the  models  and 
other  tools  needed  by  a  broad  spectrum  of  ES  stakeholders  for  preparation  and 
response  and,  considering  the  results  of  the  gap  analysis,  with  developing  a  mis¬ 
sion  needs  statement,  an  operational  requirements  document,  and  a  concept  of  op¬ 
erations.  This  report  is  the  operational  requirements  document.  It  describes  both 
the  functional  requirements  for  software  and  the  operational  capabilities  needed  to 
implement  and  support  that  software. 

Background 


According  to  good  software  development  practices,  before  software — whether  a 
model  or  another  type  of  tool — is  built  or  bought,  requirements  for  the  software 
must  be  developed.  Requirements  for  what  the  software  must  do  and  how  it  must 
behave  are  called  functional  requirements.  Other  requirements,  called  operational 
requirements,  describe  operational  and  support  concepts  in  sufficient  detail  for 
program  and  support  planning.  Both  functional  and  operational  requirements  must 
be  satisfied  to  develop  models  and  other  tools  that  will 

♦  fulfill  the  users’  needs  to  perfonn  certain  functions, 

♦  behave  the  way  users  need  it  to  behave,  and 

♦  be  adopted  and  sustained  by  the  user  community. 

The  functional  requirements  are  general  statements  of  software  needed,  and  the 
operational  requirements  are  more  detailed  statements  about  the  support  infra¬ 
structure  and  what  is  needed  to  enable  stakeholders  to  obtain  and  use  software 
models  and  tools.  The  functional  requirements  are  general  statements  because  it  is 
difficult  for  stakeholders  to  articulate  the  specifics  of  what  some  needed  software 
would  do,  without  having  seen  examples  of  different  types  of  software.  In  con¬ 
trast,  stakeholders  can  be  quite  specific  about  their  operational  requirements  be¬ 
cause  they  are  all  too  familiar  with  the  barriers  to  software  use. 
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Introduction 


Study  Approach 


This  task  called  for  interviewing  stakeholders  to  gather  information  about  the 
types  of  software  they  need  to  prepare  for  and  respond  to  a  threat.  Our  first  steps 
were  to  draft  interview  guides  (one  for  state-level  emergency  management  agen¬ 
cies,  or  EMAs,  and  one  for  local  jurisdictions)  and  construct  a  sample  of  stake¬ 
holders  who  adequately  represent  the  ES  community.  We  strove  to  include  as 
many  types  of  local  jurisdictions  as  possible,  to  correct  a  perceived  bias  in  prior 
studies  toward  larger  jurisdictions.  A  team  was  assembled  that  included  experts  in 
emergency  management,  information  technology  (IT),  and  project  and  program 
management,  as  well  as  individuals  who  are  experts  in  eliciting  and  analyzing 
software  requirements. 

The  team  interviewed  state  emergency  managers  individually  and  conducted 
group  interviews  with  local  jurisdictions  to  include  as  many  disciplines  (emer¬ 
gency  management,  fire,  law  enforcement,  public  works,  medical,  transportation, 
etc.)  as  possible.  In  addition,  the  team  interviewed  non-governmental  organiza¬ 
tions  (NGOs)  to  understand  their  needs  and  their  relationships  with  and  depend¬ 
encies  on  their  government  counterparts.  We  wanted  to  consider  the  role  of  NGOs 
because  they  are  an  integral  and  important  part  of  many  communities  across  the 
nation.  In  other  words,  we  wanted  to  understand  how  local  jurisdictions  can  work 
with  their  community  counterparts  and  how  shared  models  and  tools  might  be 
utilized  in  the  field.  A  total  of  90  individuals  participated  in  the  interviews.  Ta¬ 
ble  1-1  summarizes  the  demographics  of  the  interview  participants. 

The  team  completed  a  total  of  48  individual  and  group  interviews  between  March 
and  August  2008;  14  of  these  were  with  state-level  employees,  and  32  were  with 
local  jurisdictions  (two  jurisdictions  required  a  second  interview).  These  jurisdic¬ 
tions  were  of  various  sizes  and  types  (rural,  city,  county,  tribal,  and  large  urban 
areas)  and  in  a  variety  of  geographic  locales  (island,  mountainous,  coastal,  and 
plains  areas).  All  interview  participants  contributed  voluntarily,  and  all  informa¬ 
tion  was  obtained  based  on  the  understanding  that  it  was  not  for  attribution. 

The  team  used  a  consistent  process  for  all  interviews.  First,  letters  were  sent  to 
those  in  our  sample  to  let  them  know  of  the  study.  Then,  we  discussed  the  inter¬ 
view  concepts  and  process  with  four  individuals  at  the  state  level,  refined  the  in¬ 
terview  guides,  and  began  scheduling  interviews.  In  advance  of  each  interview 
(whether  state  or  local),  the  team  sent  participants  the  interview  guide  and  a  de¬ 
scription  of  the  purpose  of  the  study  and  areas  of  interest.  At  the  local  level,  the 
interview  included  questions  on  local  hazards;  planning,  training,  and  exercising; 
response  operations;  recovery;  daily  use  of  computer  tools;  funding;  and  any  topic 
the  interviewees  wanted  to  discuss.  Interviews  were  conducted  by  teleconference; 
interviewees  were  offered  a  copy  of  the  notes  taken,  if  they  so  wished.  In  addi¬ 
tion,  we  collected  infonnation  from  the  interviewees  about  the  software  and  other 
tools  that  they  use.  Appendix  A  lists  them. 
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Table  1-1.  Demographics  of  the  Interview  Participants 


Population 

Jurisdictions 

EMA 

Fire 

Police 

Public 

works 

Medical 

Elected 

Other 

Total 

1-14,999 

1  county,  1  city, 

1  tribe 

3 

2 

5 

15,000-49,999 

2  counties 

2 

1 

1 

1 

5 

50,000-99,999 

2  counties 

3 

1 

4 

100,000-249,999 

7  cities,  2  counties, 

1  tribal  consortium 

9 

10 

2 

2 

3 

1 

27 

250,000-499,999 

3  cities,  4  counties 

H 

1 

1 

2 

11 

500,000-999,999 

4  cities 

B 

2 

2 

1 

3 

1 

13 

1,000,000-4,999,999 

1  county,  1  NGO 

i 

1 

1 

3 

Over  5,000,000 

1  city,  1  NGO 

B 

1 

1 

3 

States 

1 0  states 

1 

15 

Pretest 

State 

4 

Total 

44 

15 

6 

3 

13 

2 

3 

90 

The  team  analyzed  the  interview  notes  and  the  infonnation  on  software  and  other 
tools  used  by  the  interview  participants  to  develop  this  operational  requirements 
document. 

Organization  of  T his  Report 


The  remainder  of  this  report  is  organized  as  follows: 

♦  Chapter  2  describes  the  functional  requirements  that  the  software  must 
perform  to  support  the  preparation  for  and  response  to  an  emergency. 

♦  Chapter  3  describes  the  operational  conditions  and  support  that  must  be  in 
place  to  ensure  the  successful  adoption  and  operation  of  the  models  and 
other  tools  needed  by  the  ES  community. 

♦  Chapter  4  presents  conclusions. 

The  appendixes  contain  supporting  detail. 
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Chapter  2 

Functional  Requirements 


Functional  requirements  describe  what  the  software  (modeling,  simulation,  and 
other  analysis  tools)  must  do  for  the  users  of  the  systems — in  other  words,  what 
functions  the  software  must  perform  to  support  the  preparation  for,  response  to, 
and  recovery  from  an  emergency.  They 
also  describe  how  that  software  must 
behave.  Some  general  software  re¬ 
quirements  apply  to  any  software  de¬ 
veloped  for  the  ES  community. 

However,  this  chapter  focuses  on  more 
specific  functional  requirements: 

♦  Continuity  of  operations 

♦  Models 

♦  Other  tools 

♦  Integration 

♦  Usability. 

The  following  sections  provide  an  over¬ 
view  of  these  requirements,  synthesized 
from  the  information  obtained  during 
interviews.  Appendix  B  contains  the 
complete  list  of  functional  requirements 
identified  by  our  interviewees. 


Continuity  of  Operations 


Requirements  Applicable  to  All  Software 

Software  must  look  and  operate  the  same, 
regardless  of  mode:  networked,  LAN  only, 
or  standalone  laptop. 

Software  must  integrate  with  other  applica¬ 
tions  easily,  scale  up,  and  use  familiar  ter¬ 
minology,  for  support  by  nontechnical 
emergency  personnel. 

Adoption  and  implementation  of  software 
must  be  possible  for  both  well-funded  juris¬ 
dictions  and  jurisdictions  with  no  overhead 
funds. 

Maintenance  of  software  must  be  very  low 
cost  and  require  minimal  technical  skills 
from  using  jurisdictions. 

Asset  management  tools  must  exchange 
data  using  some  common,  easy-to-use,  low- 
cost  or  no-cost  standard  or  format. 

Software  must  include  more  than  the  tech¬ 
nical  information  needed  to  implement  it. 
Jurisdictions  need  information  on  different 
implementation  paths  and  tools  (such  as 
checklists)  to  help  them  plan  for,  deploy, 
and  support  software. 


Because  of  the  conditions  under  which  the  ES  community  must  work — conditions 
in  which  telephone,  power,  and  other  infrastructure  may  be  compromised — 
software  must  work  in  several  modes: 

♦  Networked 

♦  Without  network  connections — standalone  computers  or  local  area  net¬ 
work  (LAN)  only 

♦  Without  electrical  power — laptop  or  hard-copy  only. 
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Figure  2-1  depicts  the  modes  of  operation. 

Figure  2-1.  Modes  of  Operation 


Local  PC 

Local  PC 

Local  PC 

Without  Electrical  or  Network  Connections/Laptop  Only 


To  the  extent  feasible,  the  software  should  look  and  operate  the  same,  regardless 
of  the  mode  of  operation.  The  ability  to  operate  seamlessly  during  normal  opera¬ 
tions  or  during  an  event  implies  the  following: 

♦  Data  stored  in  a  central  repository  must  be  redundantly  stored  locally, 
which  makes  the  data  available  to  applications,  regardless  of  location. 

♦  Single  data  entry  must  serve  both  storage  locations. 

♦  Synchronization  of  data  once  network  connectivity  is  restored  must  take 
place  without  much  effort  on  the  part  of  the  local  users. 

♦  Input  and  output  formats  must  transfer  to  paper  easily,  so  that  loss  of  lap¬ 
top  capability  does  not  impede  data  capture  and  use. 

♦  Process  flow  for  all  modes  of  operation  must  be  as  similar  as  possible. 

Local  jurisdictions  can  provide  little  support  for  overhead  functions,  such  as  train¬ 
ing  on  the  use  of  software.  Often,  local  users  are  acting  in  multiple  roles.  It  is  rare 


2-2 


Functional  Requirements 


that  they  have  any  support  for  IT,  whether  selecting  it,  installing  and  maintaining 
it,  or  operating  it.  Thus,  for  these  users  to  adopt  and  use  models  and  other  tools, 
the  software  must  do  the  following: 

♦  Integrate  with  software  used  to  support  daily  operations,  so  that  users  are 
familiar  with  the  software  and  can  readily  use  it  in  emergencies.  For  ex¬ 
ample,  event  management  models  and  other  tools  can  be  used  during  nor¬ 
mal  operations  and  during  emergencies. 

♦  Scale  up  or  down  to  accommodate  any  size 
event. 

♦  Use  terminology  and  process  flows  that  are 
familiar  to  the  users.  For  example,  to  be  as  in¬ 
tuitive  as  possible,  input  screens  should  mimic 
the  forms  used  for  manual  data  capture. 

♦  Be  available  at  little  or  incremental  cost. 

Models  and  tools  developed  for  these  users  must  accommodate  both  well-funded 
jurisdictions  that  have  IT  support  and  jurisdictions  with  little  or  no  support.  This 
may  require  designing  models  and  tools  around  mandatory  core  functions,  with 
optional  advanced  features.  Jurisdictions  with  sufficient  funding  to  provide  more 
training,  technical  support,  and  equipment  (such  as  mobile  data  tenninals  in  all 
vehicles)  could  implement  both  the  core  functionality  and  the  advanced  features. 
Core  functionality  should  be  designed  to  allow  for  infrequent  updates,  while 
modules  with  advanced  features  could  be  updated  as  frequently  as  desired. 

A  key  factor  in  a  jurisdiction’s  ability  to  adopt  a  model  or  tool  is  maintenance. 
Often,  maintenance  for  both  the  software  and  the  supporting  information  technol¬ 
ogy  precludes  the  use  of  freely  available  models  and  tools.  Although  maintenance 
is  clearly  an  operational  requirement,  it  is  so  limiting  that  it  generates  some  func¬ 
tional  requirements  for  the  software: 

♦  Models  must  be  simple  to  download  and  install.  Models  must  be  designed 
to  neither  require  changes  to,  nor  have  any  impact  on,  software  already  in 
use  by  jurisdictions. 

♦  Documentation  is  a  key  part  of  model  delivery  and  must  be  written  for  a 
nontechnical  audience. 

♦  The  release  strategy  for  models  must  take  into  account  very  limited  tech¬ 
nical  support.  For  example,  core  functionality  should  be  released  as  a  sim¬ 
ple  download  and  installation;  patches  or  incremental  upgrades  could  be 
used  for  add-ons. 


Continuity  of  Operations 

The  ES  community  needs  a 
supporting  infrastructure 
24/7,  365  days  a  year  that 
provides  peak  performance 
when  conditions  are  at  their 
worst. 
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♦  Each  model  should  have  a  support  mechanism.  Support  could  be  provided 
by  e-mail  or  telephone  help  desk,  a  users  forum  for  peers  to  help  one  an¬ 
other,  and  other  mechanisms. 

Knowing  what  resources  are  available  is  key  to  effective  response,  so  tracking  of 
assets  and  resources  is  a  very  common  requirement.  However,  to  be  effective,  as¬ 
set  tracking  tools  must  provide  the  capability  to  exchange  asset  availability  infor¬ 
mation  with  other  jurisdictions  (for  mutual  aid,  for  example).  To  do  that,  the 
assets  must  be  categorized  and  described  in  a  consistent,  standard  way.  This  calls 
for  asset  management  tools  that  do  the  following: 

♦  Use  a  common  standard  to  describe  assets.  Interviewees  mentioned  the 
National  Incident  Management  System’s  Resource  Management  Resource 
Typing  definitions,  but  said  they  did  not  want  to  adopt  them  if  they  are  not 
final. 

♦  Provide  asset  management  capability  and 
support  or  integrate  with  logistics  functions. 

♦  Provide  asset  visibility  and  tracking  for  hu¬ 
man  assets  (including  volunteers),  equipment 
(with  electronic  tracking  mechanisms),  and 
other  resources. 


♦  Provide  asset  accountability  functions. 

Tools  developed  for  state  and  local  use  should  provide  road  maps  for  state-wide 
implementation.  Currently,  when  a  state  or  county  implements  an  EM  system — 
for  example,  a  web-based  emergency  operations  center  (EOC)  or  WebEOC — 
there  is  little  coordination  with  other  county  or  local  emergency  management 
agencies  (EMAs).  Planning  for  deployment  state-  or  county-wide  must  consider, 
and  clearly  communicate,  the  following: 

♦  Identification  of  individuals  who  will  have  access  to  specific  parts  of  the 
system,  under  both  normal  and  emergency  conditions  (generally  based  on 
the  role  an  individual  plays) 

♦  Timing  and  type  of  training  that  will  be  offered  to  different  users 

♦  Use  of  multiple  modes  of  delivery 

♦  Negotiation  of  favorable  licensing  structures  across  state  lines  based  on 
bringing  multiple  jurisdictions  to  the  table  at  one  time 

♦  Compatibility  of  the  new  installation  with  previously  installed  versions 

♦  Integration  of  the  new  installation  across  existing  platfonns  and  applica¬ 
tions. 


Tools  and  Data  Exchange 

Models  and  tools  must  be 
easy  to  use  and  maintain, 
have  good  documentation, 
and  support  asset  manage¬ 
ment  needs. 
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Functional  Requirements 


Models 


A  model  is  an  approximation,  representation,  or  idealization  of  selected  aspects  of 
the  structure,  behavior,  operation,  or  other  characteristics  of  a  real-world  process, 
concept,  or  system.  A  simulation  is  a  model  that  behaves  or  operates  like  a  given 
system  when  provided  a  set  of  controlled  inputs.1 

In  the  ES  community,  users  need  models  to  assist  with  preparing  for,  responding 
to,  and  recovering  from  events  and  disasters.  They  need  information  so  they  can 
make  decisions  on  how  they  will  respond  to  various  emergency  scenarios.  One 
may  think  of  these  models  as  decision  support  tools. 

Modeling  needs  vary  from  jurisdiction  to  jurisdiction 
due  to  such  differences  as  size,  makeup,  hazards  or 
threats,  and  government  structure.  Planning  at  a  re¬ 
gional  level  can  occur  for  hazards  common  across  that 
area,  and  local  planning  would  address  threats  unique 
to  that  locality.  Therefore,  any  model  created  for  the 
ES  community  must  be  flexible  enough  to  accommo¬ 
date  the  differences.  Below  are  some  examples  of  dif¬ 
ferences  that  models  must  accommodate: 

♦  Population  density 

♦  Hazards  and  threats  (general,  regional,  seasonal,  and  industry  specific) 

♦  Government  hierarchy  (towns  vs.  townships,  for  example) 

♦  Placement  within  the  government  hierarchy  (town,  city,  county,  state,  tri¬ 
bal  nation,  territory) 

♦  Geography  (for  example,  percentage  of  land  in  agriculture  or  island  vs. 
continental) 

♦  Resources 

>  Equipment  (locally  controlled  and  otherwise  available  in  an  event) 

>  Human  resources,  including  types  of  volunteers  and  NGOs 

>  Funding  sources 

1  Dr.  Charles  Hutchings,  “Modeling  and  Simulation  for  Homeland  Security”  (presentation. 
National  Defense  Industrial  Association  Modeling  and  Simulation  Committee,  June  2008). 

Dr.  Hutchings,  the  director  of  the  recently  established  office  for  modeling  and  simulation  within 
DHS/S&T’s  Test  and  Standards  Division,  is  developing  the  modeling  and  simulation  vision  and 
strategic  plan.  To  ensure  that  our  efforts  coordinate  with  Dr.  Hutchings’s  emerging  strategy,  we 
used  his  definitions  for  modeling  and  simulation,  and  we  will  comply  with  any  standards  from  that 
office  as  they  evolve. 


At-a  -Glance 


In  simple  terms,  a  model  is 
a  computer-based  repre¬ 
sentation  of  a  real-world 
system;  a  simulation  is  a 
representation  of  the  opera¬ 
tion  of  a  system  over  time. 
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♦  Levels  of  authority/degree  of  autonomy 

♦  Types  of  public  services  provided. 

As  one  can  imagine,  the  current  modeling  capabilities  of  the  ES  community  cover 
a  wide  range — from  nonexistent  to  quite  sophisticated.  Available  resources,  both 
human  and  financial,  are  the  drivers  of  the  ability  of  a  given  jurisdiction  to  model 
events  and  their  plans.  In  other  cases, 
threats  encountered  by  a  jurisdiction  affect 
the  ability  to  accurately  model  what  they 
are  most  likely  to  face.  In  addition,  access 
to  appropriate  and  current  data  plays  a 
large  role  in  the  ability  of  a  jurisdiction  to 
produce  usable  model  results. 

Overall,  our  interviewees  described  more 
specific  requirements  for  software,  and  for 
integration  of  software,  than  they  did  for 
specific  models.  They  do  not  perceive  that 
lack  of  modeling  tools  is  an  urgent  need, 
perhaps  because  they  are  very  comfortable 
working  without  the  various  software  tools 
(such  as  asset  management  software)  and 
operate  day-to-day  using  more  basic  tools, 
such  as  word  processing  and  spreadsheets. 

In  addition,  they  have  a  limited  under¬ 
standing  of  how  models  could  work  for 
them  and  what  impact  models  could  have. 

When  interviewees  identified  a  modeling 
need,  it  was  in  the  context  of  the  prepara¬ 
tion  phase.  However,  they  also  stated  that 
they  needed  to  use  the  same  tools  when  responding  to  an  event.  In  other  words, 
models  used  for  planning  must  also  be  usable  to  support  response,  including  input 
of  new  data  as  an  event  unfolds.  Using  the  same  models  and  data  in  both  the 
preparation  and  response  phases  enables  the  smooth  transition  to  a  constantly 
changing  response  mode.  They  were  not  generally  aware  of  the  benefits  of  using 
modeling  tools  for  developing  exercises. 

In  interviews,  the  ES  community  requested  several  specific  types  of  models  and 
other  tools  to  support  the  decisions  they  need  to  make  during  an  emergency: 

♦  Risk  analysis 

♦  Mass  casualty  estimation 

♦  Evacuation  planning 


Factors  Affecting  the  Use  of  Models 
by  a  Jurisdiction 

Threats  for  which  the  jurisdiction  must 
plan: 

■ 

Level  of  funding/tax  base 

■ 

Sources  of  revenue  within  the  ju¬ 
risdiction 

■ 

Form  of  government 

■ 

Degree  of  autonomy/level  of  au¬ 
thority 

■ 

Organizational  position  and  sup¬ 
port  of  response  agencies  within 
government 

■ 

Size  of  the  jurisdiction 

■ 

Terrain 

■ 

Location  and  type  of  critical  in¬ 
frastructure 

■ 

Population  density 

■ 

Special  and  seasonal  events 

■ 

Access  to  and  distance  from  ex¬ 
ternal  resources 

■ 

Availability  of  data  to  input  to 
models. 
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Functional  Requirements 


♦  Scenario-based  planning 

♦  Earthquake  modeling 

♦  Situational  awareness 

♦  Resource  tracking 

♦  Weather  estimation 

♦  Simulations  for  training  and  exercising. 

The  following  subsections  address  each  of  these  types  of  models. 

Risk  Analysis 

A  common  requirement  raised  in  interviews  with  jurisdictions  of  all  types  is  mod¬ 
eling  to  support  risk  analysis.  Although  some  jurisdictions  use  tools  for  specific 
threats — for  instance,  HAZUS  for  flooding,  hurricane  winds,  and  earthquakes  and 
CAMEO,  ALOHA,  and  MARPLOT  for  hazardous  material  risk — overall,  risk 
modeling  is  done  inconsistently  across  the  ES  community.  Many  jurisdictions  do 
not  even  use  freely  available  tools.  This  may  be  due  to  their  limited  understanding 
of  how  models  could  work  for  them  and  what  effect  the  models  could  have.  It 
may  also  be  due  to  a  lack  of  human  and  computer  re¬ 
sources  to  support  training  and  use  of  such  tools. 

Jurisdictions  need  models  to  support  three  types  of 
risk  analyses: 

♦  Overall  risk  assessments.  Risk  assessment 
provides  a  general  overview  of  the  most  prob¬ 
able  threats  that  could  occur  in  a  jurisdiction. 

Risk  analysis  helps  jurisdictions  to  more  fully  analyze  all  threats  and  haz¬ 
ards  and  to  prioritize  efforts  for  the  variety  of  threats  they  may  face.  Juris¬ 
dictions  can  then  allocate  appropriate  effort,  time,  and  resources  to 
preparing  for  threats  posing  the  most  risk  to  their  community.  A  jurisdic¬ 
tion  can  develop  a  quick  and  simple  overview  of  potential  threats  by  using 
FEMA’s  Vulnerability  Analysis  Chart,  a  basic  matrix  into  which  the  juris¬ 
diction  adds  its  empirical  knowledge  of  the  area,  along  with  information 
about  available  resources  and  capabilities.2  (Appendix  C  contains  an  ex¬ 
ample  of  how  the  chart  is  used.) 

♦  In-depth  analyses  of  high-risk  hazards  and  threats.  Specific  threat  analysis 
enables  jurisdictions  to  further  refine  their  plans  and  allocate  preparedness 
resources  appropriately.  Resulting  output  from  a  specific  threat  analysis 
becomes  the  input  to  a  response  model,  as  well  as  inputs  to  training  and 

2  The  chart  is  available  at  http://www.fema.gov/business/guide/sectionlb.shtm. 


Risk  Models 


Many  jurisdictions  are  not 
using  existing  risk  modeling 
tools,  either  because  they 
are  unaware  that  they  exist 
or  they  have  limited  knowl¬ 
edge  of  the  tools  and  their 
capabilities. 
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exercise  scenarios.  Freely  available  analysis  tools  exist  for  specific  haz¬ 
ards  such  as  floods,  hazardous  materials,  earthquakes,  and  hurricanes. 

♦  Analyses  of low -probability /high-impact  threats.  Typically,  these  types  of 
threats  (for  example,  an  earthquake  or  a  terrorist  attack)  get  little  attention 
beyond  the  overall  risk  analysis  because  the  probability  of  occurrence  is  so 
low,  and  the  more  likely  hazards  and  threats  use  all  the  available  planning 
resources.  As  a  result,  jurisdictions  focus  their  planning  resources  on  the 
more  likely  threats.  Another  difficulty  is  that  estimates  of  the  probability 
of  an  event  often  are  based  on  history;  thus  unprecedented  events  (for  ex¬ 
ample,  the  scale  of  Hurricane  Katrina)  may  get  little  attention  in  specific 
hazard/threat  analysis.  Nevertheless,  these  threats  must  be  assessed  and 
planned  for  appropriately.  For  example,  the  majority  of  the  threats  repre¬ 
sented  in  the  NPSs  were  regarded  by  our  interviewees  as  low-probability 
threats,  yet  they  have  a  potential  impact  at  the  level  of  the  9/11  attacks. 
Without  planning  at  the  local  level  for  these 
threats  and  incorporating  the  changes  into  ex¬ 
isting  plans,  our  response  to  these  disasters 
will  be  little  improved  from  our  response  in 
2001. 

Risk  models  may  require  some  additional  tools  to  be 
fully  effective.  For  example,  once  the  specific  threat 
analysis  is  complete,  its  output  is  used  to  develop  the 
response  plan.  Methods  for  developing  response  plans 
vary  widely,  depending  typically  on  whatever  tools 
the  planner  has  available.  One  interviewee  requested  a 
standard  tool  to  do  SWOT  analysis  (analysis  of 
strengths,  weaknesses,  opportunities,  and  threats). 

SWOT  analysis  is  used  frequently  in  other  settings, 
but  no  standard  method  has  been  developed  for  use  in  the  ES  community.  SWOT 
analysis  would  allow  planners  to  directly  map  specific  threats  to  various  factors, 
such  as  planned  mitigation  efforts  or  memorandums  of  understanding  (MOUs), 
based  on  their  expected  positive  impact. 

With  the  variety  of  threats  for  which  the  ES  community  must  plan,  professionals 
need  accurate  supporting  data  to  analyze  the  various  threats  at  the  level  of  detail 
necessary.  Jurisdictions  also  require  the  ability  to  model  capabilities  needed  to 
respond  to  an  event. 

The  reality  of  obtaining  executive  and  budgetary  support  to  prepare  for  any  spe¬ 
cific  threat  is  most  often  dependent  on  a  community’s  resources  and  the  relative 
level  of  risk.  Funding  may  be  declined  for  a  low-level  threat  when  weighed 
against  other  critical  impending  priorities,  even  if  the  potential  consequences 
could  be  exceedingly  high.  The  potential  low  level  of  risk  is  often  felt  to  be  ac¬ 
ceptable  because  officials  consider  it  unlikely  to  occur  in  the  foreseeable  future, 
meaning  their  tenn  in  office. 


Risk  Analysis 

Risk  analysis  is  the  first 
step  in  threat  analysis  and 
planning.  If  the  investment 
in  tools  is  not  made  to  sup¬ 
port  this,  then  jurisdictions 
will  not  be  sufficiently  pre¬ 
pared  to  handle  threats  and 
disasters.  Jurisdictions 
need  to  perform  overall  risk 
assessments,  in-depth 
analyses  of  high-risk  haz¬ 
ards  and  threats,  and 
analyses  of  low-probability/ 
high-impact  threats. 
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Functional  Requirements 


Mass  Casualty  Estimation 

A  primary  responsibility  during  the  response  phase  is  to  manage  the  care  and 
movement  of  those  casualties  needing  assistance.  To  do  so  expediently,  inter¬ 
viewees  at  every  level  of  emergency  management  noted  the  need  for  a  model  to 
estimate  how  many  people  will  require  which  types  of  services  and  what  re¬ 
sources  will  be  needed  to  transport  them  to  the  health  care  facility  that  can  best 
manage  their  care.  The  model  will  enable  the  ES  community  to  envision  the  num¬ 
ber  and  types  of  casualties  that  may  result  from  a  given  incident.  Even  if  the  out¬ 
put  of  the  model  shows  that  casualties  would  overwhelm  capabilities  and 
resources,  it  would  provide  reliable,  defensible  estimates  for  making  the  case  for 
budgetary  support,  for  mutual  aid,  for  requesting  Federal  Metropolitan  Medical 
Response  System  assistance,  etc.  The  model’s  output  must  then  become  the  input 
to  plans,  to  provide  the  capability  for  managing  such  an  event  in  a  given  jurisdic¬ 
tion.  Such  models  must  be  user  friendly,  easy  to  update  frequently,  and  able  to 
process  inputs  quickly  during  an  event,  under  adverse  operating  conditions,  with 
complicating  factors  such  as  fatigue  and  stress. 

Evacuation  Planning 

Interviewees  requested  models  to  assist  them  with  planning  evacuations  under  a 
number  of  scenarios,  including  a  variety  of  complicating  factors.  Some  interview¬ 
ees  can  use  a  geographic  information  system  (GIS)  to  overlay  flood  maps  to  iden¬ 
tify  areas  that  may  need  to  be  evacuated,  and  some  can  even  integrate  that  with 
reverse-91 1  systems.  But  none  of  those  interviewed  can  model,  for  example,  the 
use  of  a  variety  of  vehicle  types  and  capacities,  such  as  buses,  to  evacuate  urban 
sectors,  or  the  numbers  of  vehicles  coming  from  different  areas  overlaid  on  the 
real-time  capacity  of  the  roads  in  the  area. 

Evacuation  modeling  is  particularly  important  because  exercises  to  simulate 
evacuation  are  infeasible;  they  require  too  many  participants,  and  they  can  tie  up 
traffic,  negatively  affecting  business  and  transportation.  However,  evacuation 
modeling  is  immature;  the  need  for  such  modeling  provides  a  potential  opportu¬ 
nity  for  a  variety  of  groundbreaking  research  and  development  efforts. 
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Scenario-Based  Planning 

From  a  federal  perspective,  the  NPSs  are  a 
key  planning  requirement  for  all  jurisdictions, 
regardless  of  location,  size,  etc.,  throughout 
the  United  States.  Almost  all  interviewees  ac¬ 
knowledged  the  importance  of  the  NPSs,  but 
noted  that  the  specific  threats  in  the  NPSs  do 
not  align  well  with  the  highest-probability 
threats  in  their  jurisdiction.  In  addition,  they 
believe  that  addressing  the  NPSs  in  their  plans 
places  an  undue,  and  inadequately  funded, 
burden  on  communities,  especially  where  re¬ 
sources  are  extremely  limited.  Because  local 
jurisdictions  are  minimally  funded  to  respond 
to  the  most  likely  threats  and  hazards,  with  no 
surplus  of  funding  for  low-probability/high- 
risk  threats,  they  generally  do  not  plan  for  any 
of  the  NPSs,  with  the  exception  of  pandemic 
influenza,  for  which  some  larger  jurisdictions 
have  received  grant  funds  to  develop  plans.  This  need  to  plan  for  the  NPSs  is 
linked  to  the  need  to  estimate  mass  casualties  and  to  the  requirement  to  support 
modeling  and  planning  for  low-probability/high-impact  risks. 

Jurisdictions  would  be  able  to  plan  for  the  15  NPSs  if  they  had  a  model  that  sup¬ 
ported  estimating  casualties  and  that  automatically  computed  required  resources 
(using  the  guidelines  in  the  Target  Capabilities  List).  The  following  are  key  NPS 
modeling  requirements: 

♦  Users  must  be  able  to  enter  certain  parameters  describing  the  demograph¬ 
ics  and  conditions  in  their  jurisdiction. 

♦  Models  must  provide  estimates  of  needed  resources  and  capabilities. 

♦  Model  outputs  must  be  exportable  in  common  formats  for  local  detailed 
planning  efforts. 

♦  A  repository  must  be  provided  for  centrally  maintained  standard  models. 

One  tool — Electronic  Mass  Casualty  Assessment  and  Planning  Scenarios 
(EMCAPS) — has  already  been  designed  to  model  most  of  the  NPSs.  Figure  2-2 
shows  the  user  entry  screen  for  EMCAPS. 


National  Planning  Scenarios 

Improvised  nuclear  device 
Aerosol  anthrax 
Pandemic  influenza 
Plague 
Blister  agent 

Toxic  industrial  chemicals 
Nerve  agent 
Chlorine  tank  explosion 
Major  earthquake 
Major  hurricane 
Radiological  dispersal  device 
Improvised  explosive  device 
Food  contamination 
Foreign  animal  disease 
Cyber  attack 
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Functional  Requirements 


Figure  2-2.  EMCAPS  User  Entry  Screen 


Most  interviewees  were  unaware  of  its  existence.  EMCAPS  could  help  state  and 
local  jurisdictions  articulate  specific  requirements  for  the  needed  modeling  tools 
for  the  NPS  and  mass  casualty  scenarios.  EMCAPS  could  be  used  in  a  joint  appli¬ 
cation  development  environment  as  a  prototype  to,  for  example,  show  users  what 
is  feasible  and  help  them  understand  how  much  explanation  is  needed. 

Earthquake  Modeling 

Jurisdictions  plan  for  many  different  types  of  events.  However,  one  natural  disas¬ 
ter  event — an  earthquake — stood  out  as  a  specific  modeling  need.  Although 
HAZUS  (http://www.fema.gov/plan/prevent/hazus/index.shtm)  is  available  for 
earthquake  modeling,  as  well  as  for  wind  and  flood  modeling,  most  interviewees 
seemed  to  be  unaware  of  the  tool.  Those  who  know  about  HAZUS  believe  that  it 
does  not  provide  sufficient  analysis.  The  ability  to  integrate  earthquake  modeling 
with  other  types  of  models  (such  as  evacuation  models)  and  related  planning  tools 
is  key  in  order  to  create  a  comprehensive  view  of  the  disaster  landscape. 

Situational  Awareness 

One  of  the  main  issues  for  responders,  with  respect  to  modeling  scenarios  across 
the  preparedness  and  response  phases,  is  the  ability  to  keep  up  with  changing 
conditions,  as  well  as  information  such  as  response  resources,  as  an  event  or 
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incident  unfolds.  Interviewees  were  able  to  state  the  general  need  for  some  tools, 
but  contributed  little  infonnation  on  specific  requirements. 

During  response,  responders  work  from  the  plan  or,  in  some  cases,  purely  from 
experience,  adapting  on-the-fly  to  suit  the  actual  event  conditions.  If  the  model 
that  was  used  to  develop  the  response  plan  is  updated  to  reflect  the  change  in  con¬ 
ditions,  the  model  itself  may  be  used  to  provide  accurate,  sharable  information  for 
situational  awareness. 

Resource  Tracking 

Once  the  situation  changes,  the  resources  being  applied  to  an  incident  will  need  to 
change.  Therefore,  responders  need  to  know  the  availability  of  their  own  re¬ 
sources  and  of  those  available  from  other  jurisdictions.  To  meet  that  need,  juris¬ 
dictions  need  a  way  to  track  their  resources  and  to  share  that  information  with 
other  jurisdictions.  Interviewees  were  aware  of  the  needed  restrictions  on  viewing 
of  others’  resources,  but  discussed  the  possibility  of  using  a  shared  application  for 
resource  inventories  for  all  jurisdictions  that  operate  from  a  shared  EOC.  The 
EOC  would  be  able  to  see  all  the  resource  data,  but  access  by  others  must  be  con¬ 
trolled  on  a  need-to-know  basis.  For  example,  each  jurisdiction  could  see  data  on 
its  own  resources  (equipment,  skilled  personnel,  etc.)  and,  under  certain  condi¬ 
tions  (need  to  know),  data  on  the  resources  available  to  them  from  other  jurisdic¬ 
tions. 

A  clear  picture  of  how  an  event  is  unfolding  is  crucial  to  the  success  of  the  efforts 
of  responders  and  other  emergency  personnel.  If  resource  deployment  infonnation 
can  be  integrated  with  GIS-based  event  models,  an  even  clearer  operating  picture 
can  be  provided.  The  timeliness  and  ease  of  integration  of  the  data  to  create  that 
picture  is  key;  the  ES  community  requires  real-time  capability  with  respect  to 
event  conditions  as  well  as  resource  availability. 

Weather  Estimation 

Interviewees  asked  for  a  model  to  address  weather-related  data.  Specifically,  they 
want  a  model  that  includes  details  such  as  inches  of  rain  per  hour  for  flooding, 
snow  pack  in  the  mountains  that  could  result  in  spring  flooding,  and  other  weather 
events/statistics. 

Potential  flooding  should  be  modeled  using  GIS  and  overlaid  on  the  current  flood 
plain  maps  and  should  take  into  account  the  potential  for  damage  caused  by  debris 
loading  of  the  floodwaters.  For  example,  the  amount  of  debris  picked  up  by 
floodwater  in  a  mountainous  region  heavily  laden  with  timber  fall  and  underbrush 
may  destroy  a  bridge  on  the  way  to  lower  elevations,  while  the  same  amount  of 
floodwater  on  an  open  plain  with  little  vegetation  and  little  infrastructure  would 
have  a  totally  different  effect. 
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Functional  Requirements 


Simulations  for  Training  and  Exercising 

Preparing  for  an  event  requires  that  people,  plans,  and  systems  be  trained  and  ex- 
ercised.  Training  personnel — whether  with  distance-learning  tools,  models,  or 
technology  or  with  respect  to  standards  and  plans — is  difficult  due  to  the  lack  of 
funding  and  time  and  to  the  high  staff  turnover  in  the  ES  community.  Often,  per¬ 
sonnel  cannot  give  up  hours  spent  taking  care  of  day-to-day  requirements  of  their 
job  in  order  to  train;  they  have  too  much  on  their  plate  already  and  may  have  mul¬ 
tiple  roles  as  well. 

To  address  these  problems,  jurisdictions  require  models  that  enable  them  to  create 
simulated  exercises  that  closely  represent  reality.  In  general,  computer-based 
models  can  offer  a  virtual-reality  view  into  events,  be  scenario  based,  cover  the 
many  roles  that  one  person  may  have  during  a  given  event,  and  represent  much  of 
what  an  actual  response  might  look  like  to  a  responder.  Moreover,  such  training  is 
effective  and  efficient. 

Other  Tools 


A  tool,  by  definition,  is  an  item  that  typically  provides  an  advantage  in  accom¬ 
plishing  a  task  or  enables  the  accomplishment  of  a  task  that  cannot  be  performed 
without  the  tool.  The  general  requirements  for  ease  of  use,  survivability,  mainte¬ 
nance,  and  cost  apply  to  any  tools  that  the  ES  community  will  use  to  support 
event  management.  Some  tools  are  needed  to  assist  jurisdictions  with  complying 
with  laws,  statutes,  and  regulations  and  with  communicating  and  disseminating 
event  infonnation  to  their  local  communities.  All  tools  must  work  seamlessly  in 
day-to-day  operations  and  during  an  event. 

The  tools  that  interviewees  need  are  of  three  types: 

♦  Central  repositories 

♦  Tracking 

♦  Information  dissemination. 

The  following  subsections  address  these  requirements. 


3  The  DHS  office  for  modeling  and  simulation  references  a  National  Institute  for  Standards 
and  Technology  report  on  the  use  of  modeling  and  simulation  for  training.  The  report  is  available 
at  http://www.mel.nist.gov/msidlibrary/doc/NISTIR_7295.pdf. 
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Central  Repositories 


Many  interviewees  articulated  the  requirement  for  shared  repositories.  Specifi¬ 
cally,  they  noted  the  need  for 

♦  centralized  storage  of  information  on  assessments,  plans,  resources,  and 
other  critical  data  and 

♦  a  central  location  for  all  available  tools  that  support  preparation  and  re¬ 
sponse  efforts,  including  descriptions,  terms  of  use,  installation  guides, 
and  so  on. 

Many  jurisdictions  mentioned  that  offices  often  had  their  own  systems  and  soft¬ 
ware  that  housed  information,  but  that  sharing  the  information — both  within  ju¬ 
risdictions  across  disciplines  and  between  jurisdictions — was  difficult  or 
impossible.  The  sharing  of  tools  seems  to  be  equally  difficult,  due  to  such  things 
as  differences  in  infrastructure,  lack  of  information  on  availability  of  tools,  lack  of 
technical  understanding  of  the  tools,  and  lack  of  peer-to-peer  sharing  of  informa¬ 
tion  on  tools  in  use. 

Satisfying  the  need  for  sharing  information  on  tools,  or  the  tools  themselves,  re¬ 
quires  an  inventory  of  tools  in  use,  the  conditions  of  their  use,  their  costs,  and  the 
infrastructure  needed  to  support  them.  Figure  2-3  depicts  the  concept  of  how  this 
information  could  be  shared  via  a  central  repository. 

Figure  2-3.  Conceptual  Central  Repository  for  EM  Models  and  Other  Tools 
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Functional  Requirements 


The  following  requirements  pertain  to  central  repositories: 

♦  Document  exercises  and  simulations  based  on  information  from  other  sys¬ 
tems,  such  as  WebEOC,  to  capture  and  retrieve  after-action  reports  and 
lessons  learned  documentation 

♦  Capture  specific  information  about  events,  which  can  then  be  shared 
among  response  agencies 

♦  Provide  data  and  tools  for  risk  analysis,  deployment  and  tracking  of  avail¬ 
able  resources,  situational  awareness,  and  preparation  of  reports  and  brief¬ 
ings 

♦  Enable  users  to  discover  what  tools  others  are  using  and  what  type  of  ac¬ 
cess  exists  for  these  tools 

♦  Ensure  protection  of  sensitive  data  in  accordance  with  laws,  regulations, 
and  policies  that  provide  for  access  to  public  infonnation 

♦  Provide  locations  for  points  of  distribution  (for  resources,  supplies) 

♦  Support  management  of  regional  response  assets 

♦  Provide  state-wide  GIS  capabilities  along  with  information  on  who  owns 
the  land  and  populated  areas  and  where  property  lines  are 

♦  Be  usable  in  the  field  to  document  damages  and  losses 

♦  Provide  real-time  internal  and  external  resource  inventories 

♦  Provide  short-  and  long-term  shelter  information 

♦  Provide  access  to  plans  and  planning  information. 

In  reference  to  a  tool  that  meets  many  of  these  re¬ 
quirements,  interviewees  frequently  mentioned  Vir¬ 
tual  Alabama  as  a  tool  they  would  like  to  have  in 
their  own  jurisdictions.4  Virtual  Alabama  uses  a 
three-dimensional  interface  to  retrieve  state  asset  im¬ 
agery  and  infrastructure  data  from  a  centralized 
global  imagery  data  set.  This  data  set  transforms 
massive  amounts  of  data  into  useful  information  for 
technical  and  nontechnical  users.  As  an  example, 

Virtual  Alabama  provides  the  common  operating  pic¬ 
ture  and  situational  awareness  needed  by  Alabama’s  first  responders  to  protect 
lives  and  safeguard  citizens  before,  during,  and  after  a  disaster.  This  visualization 
tool  is  affordable,  scalable,  maintainable,  and  capable  of  employing  the  power  of 

4  Virtual  Alabama  is  available  at  http://www.dhs.alabama.gov/virtual_alabama/home.aspx. 


Sharing  Data 

It  is  difficult  for  jurisdictions 
to  share  and  exchange  in¬ 
formation.  Jurisdictions 
stressed  the  importance  of 
needing  to  share  data  and 
all  types  of  information 
through  easy-to-use,  flexi¬ 
ble,  and  adaptable  tools. 
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existing  and  evolving  Internet-based  applications.  Figure  2-4  shows  the  opening 
screen. 


Figure  2-4.  Opening  Screen  for  Virtual  Alabama 


Tracking 


When  preparing  for  and  responding  to  a  threat,  jurisdictions  need  to  track  a  wide 
variety  of  information  and,  whenever  possible  or  practical,  display  it  on  GIS.  Ta¬ 
ble  2-1  lists,  for  several  categories,  types  of  information  that  need  to  be  tracked. 


Table  2-1.  Categories  and  Types  of  Information  to  Be  Tracked 


Category 

Types  of  information 

Asset/resource 

Location 

Availability 

Deployment 

Demobilization 

Condition  needing  repair  or  replacement 

Related  costs 
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Functional  Requirements 


Table  2-1.  Categories  and  Types  of  Information  to  Be  Tracked 


Category 

Types  of  information 

Donations  receipt  and 
distribution 

Date  received 

Received  by 

From  whom 

For  whom 

Value 

Delivered  to  and  accepted  by 

Cost  of  delivery 

Financial  processes 

Implementation  of  agreements  and  contracts 

Requests  for  critical  equipment  and  supplies 

Location  and  acquisition  of  unanticipated 
equipment  and  supplies 

Responding  departments’  expenditures  for  initial 
debris  clearance  and  restoration  of  critical  key  assets 

Responders 

Initial  command-and-response  personnel  assignments 
Location  and  activity 

Location  within  buildings  and/or  underground 

Amount  of  time  in  service 

Personnel  in  rest  or  out  of  service  status 

Scheduling  and  assignments  for  a  minimum  of  24  hours 

Damages/losses 

Infrastructure 

Homes 

Businesses 

Volunteers 

Self-service  application 

Web-based  activation  and  assignment 

Skills  and  service  areas 

Location  and  activity 

Requests  for  assistance 

Date  and  time  of  requests 

From  whom 

For  what 

When  needed 

Availability  and  deployment 

Disposition/demobilization 

Victims/casualties 

Injured 

Fatalities 

Sheltered 
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Table  2-1.  Categories  and  Types  of  Information  to  Be  Tracked 


Category 

Types  of  information 

Location 

Missing 

Reported  by 

Last  known  location 

Health  condition 

Description/pictures 

Information  Dissemination 

Communication  with  the  public,  both  when  preparing  for  and  during  an  event,  is  a 
requirement  with  unique  considerations  for  the  ES  community.  Privacy  is  one 
consideration;  planners  and  responders  need  information  on  special-needs  popula¬ 
tions  such  as  non-English  speakers,  elderly  people,  handicapped  people,  tran¬ 
sients,  prisoners,  and  others.  This  information  usually  can  be  gathered  only  via 
voluntary  registration  by  those  with  special  needs;  once  collected,  this  informa¬ 
tion  requires  privacy  protections. 

Political  concerns  also  affect  the  ability  to  disseminate  definitive  infonnation  to 
the  public  related  to  (1)  what  emergency  responders  can  provide  under  rapidly 
changing  circumstances,  and  (2)  what  the  public  must  be  able  to  do  for  them¬ 
selves.  It  is  necessary  to  motivate  the  pubic  to  prepare,  but  it  often  is  politically 
undesirable  to  clearly  delineate  what  the  ES  community  can  and  cannot  do  in 
every  scenario.  There  is  never  just  one  way  to  deal  with  an  emergency;  each  situa¬ 
tion  requires  a  unique  response  to  what  is  occurring  at  the  moment  a  decision  is 
required. 

Interviewees  requested  tools  that  will  do  the  following: 

♦  Enable  them  to  disseminate  information  to  special-needs  populations 

♦  Allow  special-needs  populations  to  voluntarily  register  for  assistance  (a 
self-service  application 

♦  Enable  them  to  disseminate  information  to  the  general  public 

>  Static  infonnation — for  example,  plans,  information  on  threats,  and 
self-protective  measures 

>  Dynamic  or  real-time  information — for  example,  updates  during  an 
event. 
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Functional  Requirements 


Integration 


A  number  of  interviewees  noted  the  requirement  for  integration  of  tools.  Tool  in¬ 
tegration  refers  to  the  ability  to  link  different  software  tools  so  that  processes  of 
one  tool  can  work  with  processes  in  another  tool.  One  example  of  tool  integration 
is  data  exchange,  in  which  a  software  application  has  a  defined  way  of  passing 
packages  of  data  elements  to  another  application. 

Integrating  tools  across  the  ES  community  is  challenging  due  to  the  following  fac¬ 
tors: 

♦  Differences  along  discipline  boundaries.  Processes,  tool  sets,  and  perspec¬ 
tives  of  law  enforcement  do  not  match  those  of  public  works,  for  example. 

♦  Differences  by  level  of  jurisdiction.  For  example,  processes  and  tools  used 
in  a  county  are  different  than  those  used  at  the  city  or  state  level  to  support 
the  same  capability. 

♦  Very  wide  variety  of  tools  in  use.  Tools  range  from  contracted  services  to 
commercial  off-the-shelf  software,  to  locally  developed  applications,  in¬ 
cluding  Microsoft  Office  tools  and  Unix-based  applications. 


Our  interviewees  frequently  used  the  term  “interoperable”  to  refer  to  integrated 
software.  They  envision  interoperable — or  integrated — software  tools  in  several 
ways: 

♦  Standard  tool  suite 


♦  Stronger  communications  links  between  software  tools 

♦  Data  standards,  taxonomy,  exchanges,  and  integration. 

Standard  Tool  Suite 


The  requirement  for  a  standard  suite  of  tools  (a  standard  tool  for  each  function 
common  to  most  jurisdictions)  came  up  in  multiple  interviews.  Interviewees  spe¬ 
cially  mentioned  the  following  characteristics  that  they  need  in  a  standard  inter¬ 
operable  tool  suite: 


♦  Interoperate  at  all  population  levels  (for  small  jurisdictions  as  well  as 
large) 

♦  Extend  beyond  communications,  to  all  systems  and  all  disciplines 

♦  Have  plug-and-play  ability  that  is  recognized  by  the  desktop  operating 
systems  and  is  easily  installed 
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♦  Work  in  real  time  during  an  event,  as  well  as  in  separate  modules  for  day- 
to-day  use 

♦  Be  acceptable  to  IT  departments  as  well  as  EMAs/EOCs 

♦  Be  developed  using  a  flexible,  open  architecture  in  order  to  work  across 
systems  and  hardware. 

In  addition,  interviewees  identified  integration  needs  regarding  specific  types  of 
tools: 

♦  Integration  of  resource  inventory  databases  that  can  be  viewed  in  real  time 
during  an  event 

♦  Integration  of  storm  surge  data  with  both  flood  zone  maps  and  reverse-9 1 1 
systems 

♦  Integration  of  surveillance  and  command/control  functions  in  a  single  por¬ 
tal,  for  example,  for  pandemic  influenza 

♦  Integration  in  real  time  between  EOCs — for  visual  links,  video  streaming, 
and  data  exchange 

♦  Integration  between  GIS  and  other  tools,  along  with  information  on  which 
tools  will  integrate  with  different  GIS  products 

♦  Seamless  integration  between  different  versions  of  WebEOC  (state-level 
implementations  of  WebEOC  most  often  integrate  county  information,  but 
cities  and  other  local  jurisdictions  require  integration  as  well) 

♦  Invitation  from  larger  jurisdictions  for  virtual  participation  of  smaller  ju¬ 
risdictions  in  the  daily  use  of  EOC  software  to  share  perspectives  on  plan¬ 
ning  and  response  requirements. 

Communications 

Communications  links  between  software  tools  are  required  to  support  both  the 
requirement  for  integration  and  the  ability  to  integrate  data  between  software. 

This  linkage  can  be  either  via  LAN,  wide  area  network/Internet,  or  other  commu¬ 
nications  channels.  Below  are  some  specific  communications  requirements: 

♦  Network  connections  to  allow  all  emergency  response  satellite  locations  to 
participate  in  training 

♦  A  two-way  live  feed  with  emergency  dispatch  center  for  points  of  contact 
in  each  location  in  an  event 
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Functional  Requirements 


♦  Wireless  connections  to  integrate  computer-aided  design  data  with  field 
assessments  to  assign  and  track  activities  and  progress  of  cleanup/recovery 
crews 

♦  Satellite  communications  (to  provide  redundancy),  funded  by  grants 

♦  Stable  communication  links  for  applications;  for  example,  a  state-level 
implementation  of  WebEOC  should  include  communication  and  access 
provisions  for  local  jurisdictions 

♦  Communication  and  connections  to  integral  non-governmental  compo¬ 
nents  of  emergency  response  (such  as  the  American  Red  Cross),  which 
may  require  standards  or  policy  changes. 

Jurisdictions  require  large  amounts  of  data  and  information  in  order  to  adequately 
prepare  for  and  respond  to  an  event.  Numerous  interviewees  mentioned  that 
needed  information  often  either  is  not  available  or  is  not  collected.  Reasons  for 
this  situation  might  include  a  lack  of  resources,  time,  or  funds  or,  at  the  time  of 
the  response,  lack  of  knowledge  concerning  what  data  were  needed.  Interviewees 
also  noted  that  for  the  most  part,  the  collected  information  and  data  are  accurate, 
but  some  information  and  data  are  insufficient  or  inaccurate.  Correct  infonnation 
needs  to  be  gathered  and  placed  in  a  central  location  for  access  by  everyone.  Ide¬ 
ally,  this  infonnation  collection  process  should  be  defined,  with  validation  steps 
to  ensure  that  the  data  are  accurate,  infonnative,  and  timely. 

Once  data  are  collected,  they  must  be  stored  in  centralized  repositories  so  that 
they  are  readily  accessible.  In  addition,  the  user  roles,  pennissions,  and  access 
control  need  to  be  defined  to  ensure  that  the  proper  resources  have  read/write  ac¬ 
cess  and  to  preserve  data  integrity. 

Often,  access  to  infonnation  has  to  do  with  regulations  and  statutes  to  which  the 
jurisdictions  must  adhere,  as  well  as  with  relationships  between  and  among  juris¬ 
dictions  and  between  jurisdictions  and  the  governing  state.  These  longstanding 
relationships,  while  necessary  and  crucial  to  the  EM  process,  need  to  be  studied 
further  to  strengthen  the  communication  process  so  that  the  flow  of  information  is 
streamlined.  When  access  and  visibility  to  infonnation  is  improved,  the  relation¬ 
ships  between  jurisdictions  will  improve  as  well. 

Data  Standards,  Taxonomy,  Exchange,  and  Integration 

Providing  a  standard  tool  suite  and  strengthening  communications  links  are  not 
sufficient  to  integrate  software  applications.  The  data  flowing  between  applica¬ 
tions  must  be  interpreted  correctly  to  be  of  use.  This  requires  standardized  defini¬ 
tions  or  a  shared  taxonomy  (taxonomy  includes  relationships  among  the  terms 
defined).  Data  exchange  standards  will  provide  definitions  of  “packages,”  com¬ 
posed  of  agreed-upon  data  elements,  and  each  element’s  definition  will  conform 
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to  a  standard  vocabulary  or  taxonomy.  When  data  standards  such  as  these  are  in 
place,  true  integration  can  take  place. 

The  need  for  models  and  other  tools  to  integrate,  or  at  least  exchange,  data  easily 
is  universal;  nearly  every  jurisdiction  that  uses  software  has  requirements  for  data 
standards,  exchanges,  or  taxonomy.  The  following  are  samples  of  interviewees’ 
requests: 

♦  A  data  exchange  standard  for  electronic  tracking 
of  resource  expenditures  for  all  response  agen¬ 
cies 

♦  A  nationwide  standard  for  EM  taxonomy  and 
data  exchange  so  that  various  tools/software  can 
transmit  data  between  tools  created  by  different 
vendors  (or  for  tools  developed  in-house) 

♦  At  the  FEMA  region  level,  a  standard  on  critical  data  exchange  throughout 
the  region  or  standardization  on  a  specific  software  application. 

Interviewees  also  mentioned  requirements  for  integration  of  specific  types  of  data 
or  specific  applications.  One  common  theme  was  geographic  information;  juris¬ 
dictions  require  data  that  are  easy  to  integrate  on  simulated  maps: 

♦  Integrate  plume  data  from  CAMEO  with  GISs 

♦  Integrate  hazardous  materials  data  (for  example,  Environmental  Protection 
Agency  Tier  II  data)  with  GISs 

♦  Integrate  GISs  with  reverse-91 1  tools. 

♦  Integrate  facility  plans  of  buildings  with  GIS 

♦  Integrate  property  valuation  data  with  GIS  for  estimating  damage  and 
losses. 

General  data  integration  needs  were  universal;  every  interview  included  some  ref¬ 
erence  to  integrating  some  application  or  data,  such  as  the  following: 

♦  Asset  tracking  software  that  can  exchange  data  with  WebEOC  and  be  con¬ 
sistent  with  the  National  Incident  Management  System. 

♦  Software  that  can  capture  data,  at  the  most  granular  level  of  detail,  to  sup¬ 
port  later  aggregation  of  the  data  in  various  ways.  An  example  is  post¬ 
event  accounting;  jurisdictions  must  ensure  the  availability  of  all  pertinent 
data  to  prepare  a  governor’s  request  to  the  President  for  a  disaster  declara¬ 
tion.  However,  a  governor  often  does  not  know — before  the  event — 
exactly  what  data  will  be  needed  for  that  request. 


Standards  for  Data 


Data  standards  are 
needed  for  overall  data 
exchange,  EM  taxonomy, 
and  regional  critical  data 
exchange. 
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Functional  Requirements 


♦  Capability  to  tie  form  data  and  information  between  the  localities,  the 
state,  and  FEMA  (while  also  taking  into  account  budgeting,  funding,  thre¬ 
sholds,  and  the  like  at  all  levels).  Navigating  the  bureaucratic  paperwork 
and  workflow  should  be  easier. 

♦  Capability  to  integrate  data  across  all  tools — not  just  GIS — to  address  all 
critical  elements  required  for  event  management. 

♦  Capability  to  assess  all  tools  and  models  to  detennine  if  their  outputs  can 
support  exercises  and  training  simulations. 

♦  Capability  to  integrate  data  capture  and  reuse  the  data. 

Usability 


Usability  measures  the  quality  of  a  user’s  experience  when  interacting  with  a  sys¬ 
tem  such  as  a  website,  a  software  application,  or  any  other  user-operated  system. 
Usability  also  refers  to  how  well  users  can  leam  and  use  a  product  to  achieve  their 
goals  and  how  satisfied  they  are  with  that  process.  Usability  may  also  consider 
such  factors  as  cost-effectiveness  and  usefulness.5 

To  be  usable  and  adaptable  for  the  ES  community,  models  and  tools  should  have 
the  following  characteristics: 

♦  Easily  accessible  through  a  simple  download/install  process 

♦  Compatible  and  easy  to  integrate  with  other  commonly  used  software 

♦  User  friendly,  with  limited  technical  support  required 

♦  Easily  support  the  multiple  modes  of  operation:  networked,  without  net¬ 
work  connections  (standalone  or  LAN  only),  and  without  electrical  power 
(laptop  or  hard-copy  only). 

The  characteristics  above  are  examples  of  requirements  for  models  in  this  com¬ 
munity.  The  following  are  other  important  characteristics  for  the  models:6 

♦  Easy  to  learn.  In  jurisdictions  with  limited  resources  and  technical  sup¬ 
port,  how  quickly  can  users  teach  themselves  to  use  the  model  and  its  out¬ 
puts? 

♦  Efficient  to  use.  Once  users  have  learned  to  use  the  model,  how  fast  can 
they  accomplish  tasks? 


5  See  http://www.usability.gov/basics/whatusa.html. 

6  See  http://www.usability.gov/basics/whatusa.html. 
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♦  Memorable.  Once  users  have  used  the  model,  can  they  remember  enough 
to  use  it  effectively  the  next  time,  or  do  they  need  refresher  training? 

♦  Error  proof.  How  often  do  users  make  errors  while  using  the  model,  how 
severe  are  these  errors,  and  how  do  users  recover  from  these  errors?  For 
example,  when  a  user  updates  the  model  during  an  event  response,  the 
model  should  provide  the  necessary  validation  and  feedback  to  prevent  er¬ 
roneous  entry. 

Models  need  to  be  simple  to  navigate,  be  intuitive,  and  enable  the  user  to  interact 
with  the  model  efficiently.  Models  should  be  created  with  the  guidance  of  ES  sub¬ 
ject  matter  experts;  this  group  should  include  those  with  experience  in  both  opera¬ 
tions  and  crisis  decision  making.  Often,  models  for  the  ES  community  are  created 
by  people  who  are  outside  of  the  community  and  therefore  have  a  limited  view 
into  how  the  models  will  be  used  day-to-day.  In  fact,  many  of  the  existing  models 
are  not  designed  to  be  used  beyond  the  preparation 
phase.  Without  daily  use  in  nonnal  operations,  users 
will  not  achieve  a  level  of  comfort  with  these  neces¬ 
sary  tools. 

Because  responders  are  one  part  of  the  total  commu¬ 
nity  response  capability,  the  output  must  be  clear 
enough  for  elected  and  appointed  leaders  to  arrive  at 
critical  decisions  that  only  they  have  the  authority  to 
make.  The  proposed  suite  of  tools  should  be  able  to 
reliably  trigger  points  requiring  an  executive  decision 
and  provide  data  to  augment  the  development  of  vi¬ 
able  options.  Survivability  is  also  important  to  the  applicability  of  any  model  to 
the  ES  community.  In  order  for  models  to  be  of  any  use,  they  must  be  designed  to 
support  users  during  various  modes  of  operation.  Users  must  operate  at  peak  effi¬ 
ciency  under  disaster  conditions.  Models  should  support  both  automated  and 
manual  use,  ranging  from  normal  operations  (non-disaster),  to  complete  lack  of 
connectivity  requiring  the  use  of  paper  and  pencil.  As  a  result,  the  models  de¬ 
signed  to  serve  these  users  must  take  into  account  all  the  domain-specific  re¬ 
quirements  not  typically  encountered  by  software  development  efforts. 


Usability 

There  are  two  types  of  us¬ 
ers  in  the  EM  community: 
the  actual  application  user, 
and  the  decision  maker  us¬ 
ing  the  output  of  these 
tools.  Easy-to-use,  flexible, 
and  adaptable  tools  will 
provide  the  necessary  in¬ 
formation  and  output  for 
decision  makers  to  make 
key  informed  decisions. 
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Chapter  3 

Operational  Requirements 


Operational  requirements  describe  the  operational  conditions  and  support  that 
must  be  in  place  if  the  entire  system — people,  processes,  software,  and  so  on — is 
to  work  successfully.  Many  operational  requirements  are  critical  to  the  successful 
adoption  and  operation  of  the  models  and  other  tools  needed  by  the  ES  commu¬ 
nity.  This  chapter  addresses  the  operational  requirements  that  are  not  directly 
linked  to  one  specific  function  or  specific  requirement.  The  operational  require¬ 
ments  are  grouped  as  follows: 

♦  Coordination  and  culture 

♦  Guidance,  standards,  and  infonnation 

♦  Processes  and  interoperability 

♦  Political  issues,  policy,  and  statutes 

♦  Funding 

♦  Education  and  training. 

The  following  sections  provide  an  overview  of  these  requirements,  synthesized 
from  the  information  obtained  during  interviews.  Appendix  D  contains  the  com¬ 
plete  list  of  operational  requirements  identified  by  our  interviewees. 

Coordination  and  Culture 

Coordination 

Coordination  is  defined  as  the  cooperative  activities 
and  information  exchange  intended  to  improve  area¬ 
wide  operational  capabilities.  Many  barriers  to  coor¬ 
dination  exist.  Sometimes  coordination  is  inhibited  by 
cultural  differences;  and  sometimes  by  legal  bounda¬ 
ries  (for  example,  coordinating  resource  sharing 
across  state  boundaries).  One  way  to  categorize  coor¬ 
dination  challenges  is  according  to  the  boundaries 
across  which  coordination  is  inhibited:  within  a  juris¬ 
diction,  with  other  jurisdictions,  and  at  the  regional 
and  national  levels. 


Boundaries 


The  evolution  of  emergency 
management  from  tradi¬ 
tional  disciplines  has  re¬ 
sulted  in  “silos”  of  data, 
information,  and  processes. 
These  boundaries  hinder 
efficient  communication  and 
collaboration  among  the 
disciplines. 
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Coordination  within  a  Jurisdiction 


Coordination  within  a  jurisdiction  is  difficult  across  disciplines  or  groups.  The 
boundaries  between  disciplines  are  so  ingrained  that  most  EM  training  and  docu¬ 
mentation  is  organized  according  to  discipline.  Even  emergency  support  functions 
are  divided  along  discipline  lines.  This  contributes  to  the  differences  in  vocabu¬ 
lary,  perspective,  and  approach  in  each  discipline  and  can  result  in  separate  data 
sets,  incompatible  data,  and  the  like. 

The  following  are  key  operational  requirements  necessary  to  support  inter- 
organizational  coordination  within  a  jurisdiction: 

♦  Approaches  or  methods  for  involving  all  disciplines  (including  public 
works  and  transportation  departments)  for  transportation  and  evacuation 
modeling 

♦  Approaches  and  methods  to  easily  and  effectively  engage  all  planning  and 
general  information  sharing  across  all  disciplines 

♦  Guidance  on  how  to  properly  involve  all  the  disciplines  in  defining  and  us¬ 
ing  GIS  layers 

♦  A  process  to  share  infonnation  related  to  all  human  resources  across  disci¬ 
plines 

♦  A  process  for  coordinated  deployment  and  tracking  of  responding  person¬ 
nel  from  all  disciplines. 

Coordination  with  Other  Jurisdictions 

Coordination  with  other  jurisdictions  is  difficult. 

Differences  in  policy,  perspective,  and  priorities,  as 
well  as  levels  of  authority,  can  all  create  barriers  to 
successful  coordination. 

Interviewees  suggested  key  operational  require¬ 
ments  that  include  providing  approaches  or  methods 
to  do  the  following: 

♦  Develop  a  common  operating  picture  across 
response  agencies  and  disciplines  during  response 

♦  Implement  EOC  software  across  jurisdictional  boundaries,  for  example, 
illustrating  how  larger  jurisdictions  with  EOC  software  could  invite  par¬ 
ticipation  and  allow  smaller  jurisdictions  daily  access  to  EOC  software  for 
planning,  retention  of  training,  and  ease  of  use  during  an  event  or  incident 


Coordination 


Coordination  challenges  exist 
within  jurisdictions,  between 
jurisdictions,  and  at  the  re¬ 
gional  and  national  levels. 
Each  of  these  coordination 
challenges  must  be  met  for 
successful  emergency  plan¬ 
ning  and  operations. 
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Operational  Requirements 


♦  Track  all  requests  for  assistance  and  donations,  regardless  of  their  origina¬ 
tion,  and  track  disbursement  of  all  donations  including  funds 

♦  Link  up  with  those  who  have  expertise  and  resources  for  dealing  with  spe¬ 
cial  populations  (including  prison  populations) 

♦  Establish  agreements  with  educational  institutions  (like  community  col¬ 
leges)  for  training  and  education,  with  options  for  waiving  tuition  for 
emergency  services  personnel. 

Coordination  at  the  Regional  and  National  Levels 

The  following  are  key  operational  requirements  to  enhance  coordination  and  con¬ 
sensus  at  the  regional  and  national  levels: 

♦  Guidance  at  the  federal,  FEMA  region,  state,  and  local  levels  on  data  and 
information  sharing 

♦  Documentation  (after-action  reports,  exercises,  and  simulations)  that  is 
consistent  nationwide  and  is  locatable  and  usable  by  others 

♦  Maintenance  of  casualty  estimation  studies  and  other  casualty  infonnation 
(even  anecdotal)  in  a  national  clearinghouse. 


Culture 


Culture  reflects  both  perceptions  and  practices  of  a  specific  group.  Cultural  differ¬ 
ences  often  exist  between  disciplines,  jurisdictions,  levels  of  government,  and 
within  government  conglomerates  of  merged  agencies.  These  various  cultures  of¬ 
ten  prove  to  be  inhibitors  of  coordination,  progress,  change,  and  innovation,  and 
they  affect  the  open  exchange  of  critical  information. 

During  a  crisis,  the  emergency  response  community  is  tight-knit;  for  example, 
resources  are  often  shared  between  jurisdictions.  Helping  one  another  is  second 
nature,  and  for  emergency  responders,  rolling  up  sleeves  and  “doing”  is  the  most 
natural  action.  Most  communication  occurs  person-to-person;  within  a  jurisdic¬ 
tion.  In  smaller  jurisdictions,  everyone  knows  everyone  and  things  get  done  over 
the  phone  or  in  meetings.  Most  planning  coordination  occurs  in  meetings  in  which 
people  tend  to  use  their  experience  and  the  experience  of  others  as  data  and  input 
into  planning  and  exercising.  However,  cultural  differences  may  also  be  reflected 
in  the  individual  disciplines’  plans. 

Operational  requirements  specifically  related  to  programmatic  components  of  the 
EM  community  and  universally  to  the  ES  culture  include  the  following: 

♦  An  integrated  process  to  define  the  roles  of  the  disciplines,  the  key  respon¬ 
sibilities,  and  both  the  shared  and  the  role-specific  privileges  of  operations 
management  software. 
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♦  Expanded  use  of  computer  tools  that  will  assist  with  integrating  the  pre¬ 
paredness  efforts  of  multiple  jurisdictions  and  multiple  disciplines  and  that 
will  promote  the  establishment  of  a  culture  of  sharing. 

♦  Communication  links  between  jurisdictions  regardless  of  population  and 
resource  size. 

♦  Decision  support  information  from  a  trusted  source  in  this  community.  If 
the  models  and  their  outputs  are  to  be  trusted,  the  inputs  to  the  models  and 
the  models  themselves  must  be  trusted  by  the  users. 

♦  Models  and  tools  provided  must  be  built  with  the  users,  and  they  should  be 
able  to  see  the  provenance  of  the  models  and  the  data. 

A  key  theme  of  these  requirements  is  the  need  for  software  that  is  compatible  with 
the  various  disciplines  of  the  EM  culture.  Many  interviewees  mentioned  that  the 
software  being  used  by  the  ES  community  does  not  support  the  way  ES  personnel 
plan  and  respond  to  events.  To  ensure  the  successful  use  of  software  in  the  ES 
community,  the  software  design  must  consider  the  strengths  of  the  different  disci¬ 
plines  and  areas  of  expertise.  The  software  needs  to  be  flexible  and  accommodate 
all  aspects  of  the  ES  culture;  otherwise,  it  will  be  difficult  to  obtain  user  buy-in, 
and  it  will  be  difficult  to  obtain  adequate  support  from  the  executive  leaders. 
Through  the  use  of  groups,  roles,  and  privileges,  these  different  areas  can  be  rep¬ 
resented  in  many  software  applications. 

Because  the  EM  focal  point  is  often  at  a  larger  juris¬ 
diction,  smaller  jurisdictions  receive  little  guidance  or 
assistance  with  selecting  and  implementing  informa¬ 
tion  technology.  As  a  result,  the  software  selected  by 
smaller  jurisdictions  often  has  no  capacity  or  capabil¬ 
ity  to  share  data  with  other  jurisdictions.  Sharing  is 
crucial  when  an  event  requires  multiple  jurisdic¬ 
tions — either  at  the  same  level  or  at  multiple  levels — 
to  prepare  and  respond  together. 

Communication  among  jurisdictions  of  similar  size  and  resources  is  important  to 
stay  current  with  the  latest  information,  trends,  state-level  news,  and  best  prac¬ 
tices.  Larger  jurisdictions,  which  usually  have  more  resources,  could  easily  en¬ 
courage,  promote,  and  share  perspectives  on  preparation  and  response 
requirements  by  inviting  virtual  participation  of  smaller  jurisdictions  in  the  daily 
use  of  EOC  software  on  a  broader  metropolitan  basis  rather  than  just  jurisdic¬ 
tional.  This  fosters  cooperation  and  understanding  among  jurisdictions  in  a  state 
and  provides  a  means  of  communication  should  the  need  arise  during  an  event. 

The  broad-based  ES  community  must  have  trust  in  the  information  they  receive, 
the  source  of  that  information,  and  the  reliability  of  the  software.  Planning  and 
decision  making  is  crucial  in  the  various  ES  disciplines;  a  decision  can  either  save 


Culture 


Cultural  differences  often 
exist  between  disciplines, 
jurisdictions,  and  levels  of 
government  and  within 
government  merged  agen¬ 
cies.  This  inhibits  coordina¬ 
tion,  innovation,  and 
exchange  of  information. 
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Operational  Requirements 


or  cost  lives.  Trust  in  the  source  of  information  is  a  main  concern  for  interview¬ 
ees.  Presently,  most  information  they  trust  comes  from  personal  contact,  but  as 
information  sharing  becomes  automated,  they  want  assurance  that  the  infonnation 
comes  from  trusted  sources. 

Emergency  planners  are  challenged  in  today’s  world  because  of  the  complexity  of 
disasters  and  the  frequency  with  which  emergency  response  personnel  are  de¬ 
ployed.  The  ES  community  increasingly  needs  automated  solutions  that  will  allow 
better  communication  and  sharing  of  critical  information  between  and  among  dis¬ 
ciplines  and  jurisdictions;  assist  ES  personnel  with  planning  for  events;  assist  per¬ 
sonnel  with  dealing  with  a  wide  variety  of  populations,  particularly  populations 
with  special  needs  (elderly,  disabled);  and  allow  for  smaller  jurisdictions  to  inter¬ 
act  with  their  larger  counterparts  in  order  to  share  perspectives  and  exchange 
ideas  regarding  planning  and  response  needs. 

Guidance,  Standards,  and  Information 

Guidance 

The  term  “guidance”  here  refers  to  the  general  approach  that  has  been  developed 
to  assist  planning  efforts  and  that  can  be  tailored  to  meet  individual  needs.  Nu¬ 
merous  sources  of  guidance  exist  for  both  EM  and  ES  personnel  at  the  federal, 
state,  and  local  levels.  However,  no  single  authoritative  source  of  all  guidance  ex¬ 
ists.  The  following  are  operational  requirements  identified  by  our  interviewees: 

♦  An  authoritative  source  for  guidance  and  a  regular  review  process  to  en¬ 
sure  that  they  remain  viable  and  up  to  date 

♦  A  mechanism  for  the  ES  community  to  request  specific  needed  guidance, 
such  as  how  to  develop  MOUs  that  cross  state  boundaries 

♦  For  states,  assistance  with  the  development  of  guidance  that  can  be  applied 
statewide  to  promote  consistency  among  programs  and  IT  services 

♦  At  the  federal  level,  clear  differentiation  between  what  should  be  regarded 
as  “guidance”  and  what  constitutes  “standards.” 

A  gap  exists  in  the  guidance  concerning  legal  and  statutory  barriers  to  sharing  re¬ 
source  information  across  state  boundaries.  Interviewees  in  jurisdictions  border¬ 
ing  other  states  stated  that  MOUs  are  needed  with  the  neighboring  jurisdiction  in 
the  adjoining  state  to  facilitate  collaborative  planning,  sharing  of  resources,  and 
exchange  of  critical  information.  Interviewees  noted  the  difficulty  in  putting  these 
MOUs  into  place,  citing  long-standing  laws  and  regulations  as  the  primary  rea¬ 
sons  why  the  MOUs  could  not  be  established.  Other  interviewees  expressed  the 
need  for  more  MOUs  and  for  strengthening  and  updating  existing  MOUs. 
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Guidance  for  MOUs  is  needed.  Specifically,  interviewees  have  requested  tem¬ 
plates  and  sample  MOUs  for  different  organizations  and  agreements.  Although 
sample  MOUs  are  available  from  a  variety  of  sources,  the  ES  community  needs 
an  authoritative  source  for  templates  along  with  guidance  on  their  appropriate  use 
that  reflects  some  level  of  legal  review  and  counsel. 

Information  protection  and  privacy  concerns  are  a  big  issue  with  ES  preparation 
and  response  in  the  current  environment.  The  existence  of  multiple  sources  of  ap¬ 
plicable  guidance,  of  privacy  issues  such  as  those  addressed  in  the  Health  Insur¬ 
ance  Portability  and  Accountability  Act,  and  of  other  various  privacy-related 
legislation  creates  a  confusing  information  protection  environment.  The  ES  com¬ 
munity  needs  a  central  location  for  authoritative  guidance  for  information  and 
data  protection,  both  for  privacy  and  other  types  of  information  protection. 

Another  area  of  concern  to  interviewees  relates  to  a  need  for  guidance  on  software 
development  and  IT  project  life  cycles.  They  were  unaware  of  the  numerous 
software  development  life  cycle  (SDLC)  methods  available,  such  as  the  methods 
promulgated  by  the  Software  Engineering  Institute  and  the  SDLC  standards  is¬ 
sued  by  the  National  Institute  of  Standards  and  Technology.  In  addition,  inter¬ 
viewees  said  they  need  procedures  for  coordinating  with  their  local  IT 
departments,  as  well  as  software  acquisition  procedures  at  the  local  level.  Even 
when  guidance  and  procedures  exist  at  the  local  level,  they  are  almost  always  dif¬ 
ferent  than  those  of  neighboring  jurisdictions.  Guidance  and  procedures  exist  in 
some  states,  but  may  not  be  provided  or  used  at  the  local  level. 

A  simple  way  of  discovering  best  practices  vetted  by  their  peers  would  be  of  great 
use  to  the  ES  community.  Best  practices  not  only  would  be  useful  for  ES  proc¬ 
esses,  but  would  also  be  extremely  helpful  when  implementing  IT  solutions.  For 
example,  private  entities,  such  as  stadiums  and  the  entertainment  industry,  use 
commercial  software  packages  as  part  of  their  nonemergency  planning  for  secu¬ 
rity,  crowd  control,  and  other  aspects  of  event  management.  These  software  pack¬ 
ages  can  also  be  used  by  EM  personnel  to  plan  for  similar  types  of  events.  By 
regularly  using  event  management  software  or  similar  types  of  modeling  tools  for 
nonnal  operations,  EM  and  ES  personnel  could  gain  proficiency  in  the  use  of 
these  tools  for  emergencies. 

Policy  and  procedural  guidance  standardization  is  another  area  of  concern  to  in¬ 
terviewees.  The  guidance  is  often  too  high  level,  outdated,  or  simply  not  applica¬ 
ble  to  present-day  conditions,  posing  challenges  for  ES  personnel.  In  addition, 
guidance  in  one  jurisdiction  may  conflict  with  that  in  other  jurisdictions,  even 
within  the  same  county  or  state;  such  conflicts  make  preparation  and  response  dif¬ 
ficult.  Interviewees  expressed  the  need  for  policymakers  to  issue  accurate  and 
consistent  guidance  and  also  to  differentiate  between  what  should  be  accepted  as 
guidance  and  what  should  be  considered  a  standard  requiring  a  certain  level  of 
compliance. 
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Standards 


The  multidisciplinary  ES  community  uses  the  tenn  “standard”  to  describe  a  num¬ 
ber  of  things,  from  the  principles  and  practices  of  certain  disciplines,  to  detailed 
technical  specifications.  In  this  report,  the  term  “standard”  refers  to  processes, 
data  elements  and  their  definitions,  and  software. 

Interviewees  expressed  a  need  for  standards  for  the  following  items: 

♦  An  authoritative  source  to  identify  standards  in  effect  along  with  a  regular 
review  process  to  ensure  that  they  remain  viable  and  up  to  date 

♦  Criteria  and  credentials  for  ES  personnel 

♦  Asset  tracking 

♦  Response  resource  estimating 

♦  Regional  software  and  data  exchange 

♦  MOUs 

♦  Information  and  data  protection 

♦  Data  interoperability 

♦  Software  compatibility 

♦  Open  software  architecture. 

Standards  for  some  of  the  above  items  already  exist  or  are  under  development,  but 
interviewees  were  either  unaware  of  them  or  are  concerned  about  implementing 
them  without  having  some  confidence  that  all  jurisdictions  and  disciplines  would 
be  using  those  same  standards.  The  first  three  items  are  being  addressed  by 
FEMA’s  National  Incident  Management  Systems  Integration  Division.  Specifi¬ 
cally,  the  division’s  National  Integration  Center  (NIC)  is  developing  a  national 
credentialing  system  and  resource-typing  standards.  The  NIC  website  also  has  a 
Mutual  Aid  page  that  provides  samples  of  mutual  aid  agreements  and  shows  the 
linkage  to  the  standards  for  resource  typing.  Partnering  between  DHS/S&T  and 
the  FEMA  NIC  would  ensure  that  standards  are  stable  before  they  are  imple¬ 
mented  in  resource  estimation  or  asset  tracking  software. 

To  enable  sharing  of  personnel  resources  across  jurisdictions,  interviewees  re¬ 
quested  a  standard  credentialing  system  at  the  national  level  that  uses  consistent 
criteria  to  award  standard  credentials  and  titles  in  the  ES  community.  Interviewees 
also  understand  the  need  to  invest  in  asset  management  systems;  however,  be¬ 
cause  they  need  to  share  asset  availability  across  boundaries,  they  need  a  standard 
for  both  the  description  of  assets  and  for  data  exchange.  Related  to  this  is  the  need 
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for  a  set  of  standard  estimating  tools  much  like  the  Target  Capabilities  List  that 
supports  standard  estimating  for  the  NPSs. 

Interviewees  believe  that  some  opportunities  exist  to  leverage  efforts  by  individ¬ 
ual  states  and  other  jurisdictions  within  a  FEMA  region.  This  is  especially  true 
when  multiple  jurisdictions  have  implemented  the  same  vendor’s  software.  If  the 
software  is  networked  and  licensed  properly,  it  could  be  extended  or  expanded  to 
support  all  jurisdictions  within  a  state  or  even  the  entire  region. 

Interviewees  urgently  requested  standards  for  data 
interoperability  of  all  types,  especially  for  GISs.  Lack 
of  standards  in  this  area  hinders  mutual  aid  and  re¬ 
gional  response,  as  well  as  long-term  investment  in 
robust  GIS-enabled  systems. 

Software  compatibility  is  another  key  issue.  Inter¬ 
viewees  noted  the  need  for  a  standard  for  software 
compatibility,  so  software  can  be  certified  as  interop¬ 
erable.  At  a  minimum,  software  from  the  same  vendor 
must  be  compatible  across  versions.  Currently,  juris¬ 
dictions  in  the  same  state  have  bought  the  same  soft¬ 
ware,  only  to  find  it  was  incompatible  due  to 
differences  in  version.  In  addition,  some  jurisdictions  have  requested  a  standard 
that  stresses  using  a  flexible  open  architecture  for  all  software.  These  jurisdictions 
typically  are  sophisticated  in  their  use  of  information  technology,  based  on  part¬ 
nerships  with  local  universities  or  technology  firms. 

Some  standards  that  apply  to  the  ES  community  have  been  issued  by  the  Organi¬ 
zation  for  the  Advancement  of  Structured  Information  Standards  (OASIS).  The 
following  are  examples: 

♦  Common  Alerting  Protocol 

♦  Emergency  Data  Exchange  Language  Resource  Messaging 

♦  Hospital  Availability  Exchange. 

The  second  has  an  immediate  impact  on  some  of  the  functional  requirements  (for 
asset  management  tools,  for  example).  This  community  would  benefit  from  DHS 
guidance  on  the  application  of  these  OASIS  standards  and  products  from  other 
standards  bodies  in  their  IT  applications. 

Information 

EM  and  ES  personnel  need  many  different  types  of  information  when  preparing 
for  and  responding  to  events.  They  also  need  to  disseminate  information  during 
the  response  phase.  Identifying  the  specific  data  needs — such  as  regional  response 


Guidance 


A  single  authoritative 
source  of  guidance  should 
exist  for  all  personnel  to 
follow  in  areas  such  as 
sharing  information  across 
state  boundaries,  informa¬ 
tion  protection  and  privacy 
concerns,  software  acquisi¬ 
tion  and  implementation, 
best  practices,  and  stan¬ 
dardization  of  policy  and 
procedural  guidance. 
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assets,  resource  availability,  and  updated  weather  information — is  key  to  effective 
and  efficient  response.  This  information  needs  to  be  centrally  located  for  easy  and 
immediate  access  by  all  personnel. 

Information  also  needs  to  be  created  and  disseminated  to  the  public  and  coordi¬ 
nated  in  advance  with  executive  decision  makers.  Challenges  in  this  area  include 
how  to  best  educate  the  public  with  respect  to  planning,  personal  planning  re¬ 
quirements,  and  special  populations  and  privacy  concerns.  This  information  is  dif¬ 
ficult  to  gather  and  document  and  often  cannot  be  all- 
encompassing  to  serve  all  facets  of  the  public,  due  to 
the  many  different  populations  that  require  this  infor¬ 
mation.  Interviewees  expressed  the  need  for  auto¬ 
mated  solutions  to  assist  them  with  creating  and 
maintaining  public  infonnation,  as  well  as  better  ways 
of  disseminating  the  information,  such  as  using  the 
phone  book  as  a  place  to  communicate  to  the  public 
about  personal  preparation  and  standard  response  procedures. 

Another  key  set  of  data  needed  by  the  ES  community  concerns  assets,  including 
resource  estimates.  Assets  are  managed  and  tracked  in  different  ways  ranging 
from  manual  processes  to  integrated  logistics  systems.  Therefore,  it  is  difficult  to 
identify  the  assets  available  to  support  a  regional  or  a  multi-jurisdictional  re¬ 
sponse.  Because  no  standard  exists  for  asset  management  data,  it  is  difficult  to 
exchange  this  type  of  information  efficiently.  Information  on  assets  needs  to  be 
available  and  tracked  for  accountability  purposes,  so  that  personnel  can  have  an 
idea  as  to  what  is  available  and  what  resources  have  been  expended. 

Information  gathered  during  the  preparation  phase,  such  as  population  and  ad¬ 
dress  information,  should  be  available  and  shared  across  all  disciplines.  Informa¬ 
tion  sharing  among  various  disciplines  is  paramount  to  response  success.  In 
addition  to  coordinating  during  an  event,  personnel  also  need  to  prepare  collabo- 
ratively  to  ensure  that  they  can  deal  with  all  types  of  events.  Central  access  to  and 
sharing  of  information  are  important  aspects  of  this  process. 

Processes  and  Interoperability 


Information 


The  ES  community  needs 
not  only  to  have  immediate 
access  to  information,  but 
also  to  disseminate  this  in¬ 
formation  quickly  to  deci¬ 
sion  makers  and  the  public. 


Processes  represent  a  progression  of  general  steps  needed  that  can  be  modified  to 
achieve  an  objective.  Interviewees  need  processes  that  are  flexible,  adaptable,  and 
changeable  during  both  preparation  for  and  response  to  an  event.  For  the  most 
part,  interviewees  did  not  ask  for  standard  processes,  but  they  need  good  proc¬ 
esses  that  they  can  adapt  for  local  use.  Standardized  processes  will  not  fit  in  this 
community,  because  at  the  local  level,  all  processes  must  fit  the  jurisdiction’s 
conditions  at  a  given  time.  In  other  words,  no  single  standard  process  will  fit  un¬ 
less  it  is  adapted  so  much  that  it  is  no  longer  “standard.”  There  seems  to  be  a 
common  evolution  from  “process”  to  “standard”  indicated  by  interviewees,  that 
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can  occur  over  time  or  may  also  be  event  driven,  to  control  actions  such  as  eligi¬ 
bility  for  federal  funding. 

A  common  requirement  is  for  a  consistent  process  to  capture  response  data  during 
an  event.  The  EM  community  can  then  use  those  data  to  satisfy  other  needs  such 
as  analysis,  development  of  training  exercises,  reporting,  and  retention  for  future 
needs.  Better  analysis  of  response  data  would  enable  comparisons  across  response 
efforts.  However,  jurisdictions  need  a  process  for  evaluating  event  response  re¬ 
sults  and  a  method  for  using  large  events,  such  as  concerts,  as  input  to  create 
training  and  exercise  plans.  Interviewees  also  noted  the  need  for  specific  ways  to 
automate  the  retention  of  historical  data  for  use  in  estimating  future  response 
needs  for  events. 

Although  every  event  requires  adapting  the  plan  to 
event  conditions,  having  a  repeatable  process  enables 
a  lot  of  efficiencies  in  multiple  areas  such  as  planning, 
budgeting,  training,  and  resource  assignment.  Near 
the  completion  of  the  response  phase,  efforts  should 
transition  to  the  recovery  phase.  However,  interview¬ 
ees  noted  that  they  have  no  processes  for  making  a 
smooth  transition  or  for  accurately  assessing  the  recovery  phase. 

Interviewees  would  like  a  sample  process  for  local  tracking  of  assets  for  account¬ 
ability;  however,  that  process  is  dependent  on  the  existence  of  not  only  stable  data 
requirements  but  also  a  stable  federal  policy  for  funds  reimbursement.  For  exam¬ 
ple,  a  response  effort  that  has  begun  before  a  policy  change  at  the  federal  level  has 
taken  effect  should  be  subject  to  the  original  federal  policy  that  was  in  effect  at 
the  start  of  that  response  effort. 

The  above  requirements  also  suggest  that  further  process  improvement  is  needed 
in  other  key  areas.  Interviewees  need  a  change  management  process  specifically 
oriented  toward  emergency  management.  Such  a  process  would  enable  them  to 
ensure  that  lessons  learned  are  applied  and  that  response  plans  and  actions  are  im¬ 
proved. 

Most  interviewees  said  they  have  limited  IT  support  and  need  processes  to  man¬ 
age  IT  more  efficiently.  ES  personnel  would  like  to  leverage  their  peers’  experi¬ 
ence  with  implementing  software,  and  they  need  a  process  to  do  that.  As  an 
example,  they  mentioned  a  state  software  council;  they  requested  a  process  to  or¬ 
ganize  a  similar  body  at  the  regional  level.  Because  a  jurisdiction’s  processes 
must  “fit”  its  characteristics  (size,  funding,  geography,  etc.),  interviewees  need  a 
way  to  locate  and  share  information  on  IT  solutions  with  jurisdictions  that  have 
similar  characteristics. 

The  trend  toward  common  processes  should,  over  time,  enable  both  consistent 
definitions  of  data  and  greater  interoperability  between  systems.  Jurisdictions’ 
interoperability  needs  should  be  combined  with  process  improvement 


Processes  and 
Interoperability 

The  ES  community  needs 
tailorable  processes,  and 
the  supporting  systems 
should  interoperate  and 
share  data  to  achieve  a  true 
common  operating  picture. 
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requirements  to  discover  relationships  between  these  sets  of  requirements.  Inter¬ 
operability  requirements  include  real-time  access  to  current  data  across  jurisdic¬ 
tions,  disciplines,  and  systems.  For  example,  during  a  flood,  evacuation  modeling 
during  the  response  phase  requires  GIS,  updated  threat  data  (flood  levels),  and 
traffic  data.  In  addition  to  the  technical  challenges,  the  operational  requirements 
for  agreements,  and  negotiating  conditions  for  access  to  data,  must  be  addressed. 

Operational  requirements  related  to  asset  tracking  include  barcode  readers  and 
systems.  However,  before  implementing  an  asset  tracking  solution,  many  ques¬ 
tions,  such  as  the  following,  must  be  answered: 

♦  Will  there  be  a  nationwide  standard  for  these  systems? 

♦  Will  there  be  a  data  exchange  standard? 

♦  Should  emergency  managers  attempt  to  coordinate  such  systems  with 
NGOs  or  work  solely  with  other  government  jurisdictions? 

Using  proven  IT  implementation  methods,  the  nationwide  ES  community  can 
reach  consensus  on  requirements,  both  functional  and  operational,  related  to  an 
asset  management  solution  that  will  meet  its  interoperability  needs.  A  common 
concern  was  that  infonnation  entered  at  the  local  level  became  irretrievably  lost  in 
the  federal  system  and  had  to  be  resent,  sometimes  more  than  once. 

Achieving  a  common  operating  picture  is  a  difficult  undertaking,  requiring  inte¬ 
gration  of  GIS,  asset  management  and  resource  tracking,  and  many  other  applica¬ 
tions.  It  is  so  critical  to  “see”  equipment  and  personnel  status,  jurisdictions  are 
willing  to  work  toward  a  Common  Operating  Picture  (COP)  using  any  technology 
available.  Whether  this  is  done  through  videoconferencing  or  other  technology, 
implementers  need  to  know  what  they  must  consider  when  planning  and  imple¬ 
menting  the  solution.  Guidance  in  the  process  of  developing  infrastructure  for  a 
COP  would  save  much  effort  and  would  provide  a  defined  path  to  achieving  the 
goal. 

In  some  cases,  operational  requirements  may  prevent  satisfying  some  functional 
requirements.  Interviewees  requested  that  the  various  forms  required  by  state  and 
federal  agencies  and  NGOs  all  use  consistent  data  elements,  with  the  same  format 
and  definition.  This  functional  requirement  depends  on  consensus  among  all  of 
the  pertinent  organizations.  This  operational  requirement  may  be  difficult,  and 
take  a  considerable  amount  of  time,  to  satisfy.  An  alternative  might  be  to  ensure 
that  any  accepted  system  has  the  ability  to  mine  the  various  forms  for  critical  data 
elements. 


3-11 


Political  Issues,  Policy,  and  Statutes 

Political  Issues 

Political  issues  are  similar  to  policy  issues,  in  that  they  require  decisions  above 
the  operational  level  and  can  be  influenced  by  internal 
and  external  forces.  In  EM  planning,  it  is  essential 
that  potential  extraordinary  situations  be  considered, 
particularly  in  light  of  major  events,  such  as  Hurri¬ 
cane  Katrina  and  Hurricane  Rita,  during  which  the 
political  aspects  dominated  the  situation  more  than  the 
event  response  did.  Mistakes  are  more  likely  if  plans 
are  incomplete  or  outdated,  if  procedures  are  not  fol¬ 
lowed,  and  if  responsibilities  and  authorities  are  not 
clearly  understood. 

In  major  events  such  as  catastrophic  disasters  with 
mass  casualties,  EM  preparation  and  response  esti¬ 
mates  must  be  as  accurate  as  possible.  EM  planners  have  difficulty  engaging  the 
entire  community,  especially  elected  officials,  to  plan  for  scenarios  beyond  what  a 
jurisdiction  can  handle  or  to  project  estimates  beyond  a  jurisdiction’s  capability  to 
respond.  The  reluctance  can  stem  from  political  sensitivities  to  potential  negative 
outcomes.  This  greatly  hinders  EM  planning,  because  to  accurately  estimate 
budgets  and  resources  for  upcoming  years,  planning  and  response  requirements 
need  to  be  communicated  as  accurately  as  possible. 

Understandably,  elected  officials  and  business  interests  want  to  cast  their  commu¬ 
nity  in  the  best  possible  light  in  order  to  attract  businesses  and  residents  to  the 
area.  However,  no  location  is  risk  free.  In  this  respect,  a  dynamic  EM  program 
can  be  a  positive  note  in  areas  that  have  a  particularly  high  level  of  risk.  Even  in 
areas  that  seldom  experience  a  major  disaster,  the  community  wants  to  know  that 
it  is  protected  from  the  consequences  of  the  most  probable  threats,  such  as  wild¬ 
fires  in  rural  areas.  In  every  community,  people  want  to  know  how  they  will  be 
protected  and  when  they  can  resume  their  nonnal  activities. 

Figure  3-1  shows  the  frequency  and  types  of  hazard  events  that  resulted  in  Presi¬ 
dential  Declarations  from  2000  to  2007.  It  is  not  possible  to  live  in  an  area  that  is 
totally  risk  free.  Many  areas  have  not  required  a  Presidential  Declaration  but  are 
still  subject  to  potential  catastrophic  events. 


Political  Issues 


Political  issues  and  their 
ramifications  need  to  be 
dealt  with  case  by  case. 
Having  effective  communi¬ 
cation  with  the  public,  en¬ 
suring  that  executives  are 
briefed  on  pertinent  infor¬ 
mation,  and  improving  over¬ 
all  communication  are  ways 
to  navigate  through  these 
issues. 
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Figure  3-1.  FEMA  Flazard  Map 
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Issues  raised  during  interviews  related  to  the  lack  of  leadership,  differences  in  po¬ 
litical  views,  competing  priorities,  and  the  lack  of  a  cohesive  community  ap¬ 
proach.  These  factors  contributed  to  politically  motivated  decisions  that  affected 
program  funding,  local  planning,  collaborative  planning  with  adjacent  jurisdic¬ 
tions,  and  the  dissemination  to  the  public  of  information  related  to  government 
responsibilities  and  the  public’s  roles  and  responsibilities. 
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Operational  requirements  for  managing  political  issues  include  development  of 
processes  and  procedures  to  do  the  following: 

♦  Communicate  the  level  of  risk  to  the  public 

♦  Encourage  and  assist  both  residents  and  visitors  in  protecting  themselves 
during  and  following  a  disaster 

♦  Brief  new  executive  and  appointed  officials  on 

>  the  roles  and  responsibilities  of  their  positions  under  disaster  condi¬ 
tions, 

>  the  need  to  communicate  with  federal  and  state  disaster  agencies  for 
informing  them  of  conditions  and  requesting  funding  assistance, 

>  the  nature  and  scope  of  the  emergency  planning  and  response  capabil¬ 
ity  of  the  community, 

>  the  availability  and  activation  of  external  resources  if  needed,  and 

>  the  general  level  of  threat  for  the  area 

♦  Engage  the  business  community  in  the  development  of  community  action 
plans  to  assist  and  protect  businesses 

♦  Communicate,  to  the  public,  plans  for  the  resumption  of  essential  govern¬ 
ment  services  and  businesses  as  quickly  as  possible. 

If  satisfied,  these  operational  requirements  will  enable  better  planning  and  prepar¬ 
edness  by  both  jurisdictions  and  their  citizens.  They  may  also  reduce  the  number 
and  nature  of  political  decisions  that,  if  made  under  stressful  conditions,  could 
adversely  affect  response  and  recovery. 


Policy 


A  major  issue  expressed  by  interviewees  in  local  jurisdictions  is  that  policies  gov¬ 
erning  their  programs  change  too  abruptly  or  too  frequently.  These  policy 
changes,  whether  federal  or  state,  may  make  sense  at  the  level  where  they  origi¬ 
nate,  may  support  fiscally  responsible  practices,  or  may  align  with  a  new  mission 
or  vision.  However,  they  also  may  affect  the  continuity  of  services  at  the  level  of 
the  responder  community.  Other  policy  issues  raised  and  resolutions  suggested  by 
EM  personnel  affect  the  broad  spectrum  of  operations — from  administrative  and 
EM  processes  and  tools,  to  information  technology,  to  funding  and  budgeting. 
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Federal  Programmatic  and  Disaster  Response  Policies 

Federal  policy  changes  affecting  the  EM  community  take  place  more  frequently 
than  the  community  can  absorb,  and  their  impacts  can  be  significant.  Most  often, 
this  has  to  do  with  eligibility  for  federal  funding  following  a  disaster,  but  some¬ 
times  occurs  in  relation  to  the  annual  funding  process  for  the  various  federal  pro¬ 
grams  such  as  the  Emergency  Management  Performance  Grants  and  Urban  Area 
Security  Initiative  (UASI).  The  changing  policy  landscape  sometimes  hampers 
both  preparation  and  response;  responder  organizations  cannot  develop  a  plan 
with  confidence  that,  at  the  time  of  execution,  their  response  actions  will  be  in 
accordance  with  the  policy.  This  also  negatively  impacts  the  confidence  the  public 
has  in  the  willingness  and  ability  of  the  federal  government  to  act  quickly  and  re¬ 
sponsibly  when  disasters  occur. 

Jurisdictions  are  not  required  by  federal  law  to  participate  in  FEMA’s  EM  funding 
program,  but  if  they  choose  to  do  so,  they  are  required  to  share  costs.  However, 
conflicts  arise  due  to  disconnects  between  the  federal  funding  process  and  the  ju¬ 
risdictions’  budget  processes.  The  federal  program  regulations  are  generally  not 
provided  far  enough  in  advance  for  local  jurisdictions  to  work  them  into  their 
budget  for  the  upcoming  year.  The  local,  state,  and  federal  budget  processes  are 
very  much  out  of  sync.  The  result  is  an  expectation  at  the  federal  level  that  com¬ 
ponents  of  the  programs  should  be  in  place  a  year  before  many  jurisdictions  are 
able  to  budget  the  matching  funds.  Consequently, 
progress  in  the  federal  programs  then  lags  due  to  local 
budget  processes,  and  Congress  becomes  dissatisfied 
with  the  lack  of  progress.  These  policy  changes — 
especially  financial  policies — affect  all  aspects  of 
emergency  management,  because  grant  funds  are  con¬ 
strained  by  these  policies. 

Interviewees  mentioned  that  federal  policy  decisions 
often  seem  to  be  made  in  isolation,  with  little  input 
from  those  affected  by  the  decisions.  In  addition,  there  is  a  great  deal  of  frustra¬ 
tion  when  such  policies  are  required  to  be  retroactive,  especially  when  a  jurisdic¬ 
tion  is  well  into  disaster  response  activities.  For  example,  during  the  transition 
from  response  operations  to  recovery  operations  in  a  flooding  disaster,  eligibility 
requirements  were  changed,  disallowing  funding  for  recovery  and  restoration  that 
had  been  eligible  in  previous  declared  disasters.  Interviewees  also  expressed  con¬ 
cern  that  such  policy  changes  are  not  consistently  applied  from  region  to  region. 

Policies  on  Processes  and  Tools 

In  addition  to  the  policy  requirements  cited  above,  interviewees  mentioned  other 
areas  in  which  policy  changes  could  help  their  operations.  Some  of  these  relate 
directly  to  their  ability  to  use  models  and  tools  for  preparation  and  response,  and 
others  simply  streamline  some  of  their  operations,  freeing  up  resources  that  could 


Policy 

Policy  changes  are  abrupt 
and  too  frequent,  and  they 
are  inconsistently  applied 
from  region  to  region.  Fed¬ 
eral  policy  decisions  need 
to  be  effectively  communi¬ 
cated  with  ample  time  for 
compliance. 
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be  applied  to  preparation  and  response.  Specifically,  interviewees  requested  the 
following: 

♦  Policies  that  support  collaborative  planning,  risk-based  funding,  and  proc¬ 
esses  or  methods  to  resolve  inter-jurisdictional  differences  of  opinion  and 
to  address  political  issues 

♦  Policies  to  ensure  funding  for  maintaining  up-to-date  risk  analysis  in  order 
to  plan  adequately 

♦  Policies  pertaining  to  grants  management  reflecting  a  nationwide  EM  ap¬ 
proach  that  integrates  capabilities  and  re¬ 
sources  of  federal,  state,  and  local  organiza¬ 
tions 

♦  A  set  of  programmatic  and  technological  stan¬ 
dards  that  would  simplify  the  acquisition  of 
interoperable  infonnation  technology. 

Not  all  policy  issues  are  federal.  Often,  local  policies 
are  an  issue,  particularly  when  the  policies  were  de¬ 
veloped  many  years  ago.  The  historical  policy  that  established  first-responder  or¬ 
ganizations  has  not  kept  pace  to  include  and  support  the  necessary  response  sce¬ 
narios.  One  such  change  is  the  shift  of  the  first-responder  organizations  to  address 
an  increasing  number  of  low-risk/high-impact  scenarios  such  as  terrorism  or  the 
NPSs.  Because  of  the  lack  of  up-to-date  policies  to  support  these  crucial  efforts, 
organizations  struggle  to  prepare.  In  addition,  in  local  jurisdictions  where  disas¬ 
ters  occur  infrequently,  the  need  for  funding  is  generally  outweighed  by  other 
competing  priorities,  leaving  the  EM  organization  minimally  funded  and  under¬ 
staffed. 

IT-Related  Policies 

As  the  ES  community  has  matured  with  respect  to  technology  and  the  support  it 
requires,  policy  again  has  failed  to  keep  pace.  Interviewees  stated  that  with  re¬ 
spect  to  technical  support  areas,  organizations  need  to  consider  the  entire  software 
life  cycle.  Current  policies  fall  short  by  addressing  only  the  acquisition  phase, 
leaving  out  operations  and  maintenance  and  other  phases  of  the  IT  life  cycle.  The 
following  are  specific  operational  requirements  relating  to  IT : 

♦  Life-cycle  support  of  computer  systems — hardware,  software,  and  com¬ 
munications — and  IT  staffing  and  training 

♦  Federal  policies  that  provide  both  initial  funding  and  ongoing  maintenance 
of  systems  purchased  through  specific  programs  ensuring  allowable  ex¬ 
penses  under  UASI  or  other  homeland  security  programs. 


Policies 


Better  policies  are  needed 
for  processes  and  tools, 
collaborative  planning,  risk 
analysis,  grants  manage¬ 
ment,  technology  stan¬ 
dards,  IT  acquisition, 
funding  and  budgeting. 
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Operational  Requirements 


Interviewees  also  noted  that  policies  related  to  information  technology  do  not  re¬ 
quire  compliance  to  any  set  of  standards  for  data.  As  a  result,  organizations  may 
be  unable  to  effectively  implement  and  manage  an  integrated  system  incorporat¬ 
ing  communication,  GIS,  and  data-dependent  models  and  operational  processes, 
much  less  interoperate  with  other  jurisdictions.  Interviewees  need  mandated  stan¬ 
dards  for  all  software  used  throughout  the  ES  community.  The  following  are  some 
specific  operational  requirements  in  this  area: 

♦  Policies  to  encourage  and  support  vendors  that  guarantee  maintenance  of 
existing  capabilities  and  to  discourage  arrangements  with  vendors  that  are 
constantly  releasing  new  versions  or  building  new  products  with  few  sub¬ 
stantive  improvements  or  enhancements 

♦  Federal  and  state  policies  to  support  the  development  of  standards  to 

>  ensure  consistent  grant  processes; 

>  assess  current  capabilities;  and 

>  identify  functional  requirements  for  the  acquisition  of  IT  systems  and 
software,  systems  interoperability,  tracking,  mobilization,  decision 
support,  and  record  keeping 

♦  Policies  at  all  levels  for  data  management  and  administrative  processes 

♦  Policies  to  support  regular  training  and  exercises  for  all  response  person¬ 
nel 

♦  Policies  to  ensure  continuity  of  purpose  and  executive  support  from  ad¬ 
ministration  to  administration. 

Funding/Budgeting  Policies 

Interviewees  identified  the  need  for  FEMA,  the  Department  of  Health  and  Human 
Services,  and  other  funding  agencies  to  standardize  on  data  requested  for  budget¬ 
ing  and  accounting  from  localities  of  all  sizes.  They  would  like  grants  processes 
and  forms  to  be  standardized  across  all  federal  agencies,  to  ease  the  burden  of 
completing  the  numerous  application  forms  from  various  federal  agencies.  This 
ties  in  to  the  functional  requirement  for  a  universal  data  set  that  can  capture  and 
store  all  the  common  data,  thus  requiring  additional  input  to  address  only  the 
unique  requirements  for  any  particular  funding  source. 

Finally,  interviewees  noted  the  need  for  consistency  across  funding  agencies  re¬ 
garding  in-kind  services.  Depending  on  the  grant,  local  services  may  or  may  not 
be  counted  as  part  of  the  matching  funding.  Interviewees  need  a  federal  policy 
that  addresses  and  recognizes  the  local  funds  commitment  as  a  portion  (in-kind) 
of  the  cost  share  requirement. 
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Statutes 


One  of  the  factors  that  can  adversely  affect  response  operations  across  state  lines, 
principally  in  communities  near  the  borders,  is  the  lack  of  acceptance  (especially 
among  health  care  providers)  of  a  state’s  certifications  or  licenses  by  other  states. 
Interviewees  strongly  believe  that  states  must  statutorily  establish  both  the  au¬ 
thorization  to  accept  licenses  and  a  regulatory  process  to  do  so.  Once  such  a  stat¬ 
ute  is  established,  a  computer  tool  could  be  developed  to  track  all  certified  and 
licensed  responders  coming  into  the  state  from  another  state. 

Interviews  also  believe  they  need  a  statute  addressing  the  sharing,  with  other  ju¬ 
risdictions,  of  information  on  the  availability  of  resources.  In  some  cases,  policies 
do  not  allow  infonnation  sharing  across  disciplinary  lines  and  especially  not 
across  jurisdictional  lines.  Developing  appropriate  statutory  language  would  re¬ 
quire  the  input  of  responders  and  emergency  services  officials  regarding  what  in¬ 
formation  could  be  shared,  under  what  circumstances,  and  through  what  process. 
Again,  computer  tools  could  be  beneficial  for  managing  such  exchanges  through 
the  assignment  of  privileges  within  the  system.  Such  a  capability  would  enhance 
the  total  operational  response  without  compromising  sensitive  information. 

Funding 


During  the  interviews,  it  became  very  clear  that  funding  is  one  of  the  most  critical 
factors  affecting  all  aspects  of  emergency  management.  Nearly  all  interviewees 
stated  that  funds  overall  are  insufficient  to  support  a  nationwide  emergency  pre¬ 
paredness  and  response  system  at  all  levels.  The  following  are  some  of  the  com¬ 
pounding  factors: 

♦  Funding  is  shared  among  federal,  state,  and  local  jurisdictions. 

♦  The  amount  of  paper  work  to  apply  for  and  report  on  funding — required  of 
all  local  jurisdictions,  regardless  of  size  and  staffing — is  daunting. 

♦  Funds  are  passed  through  state  EMAs  to  counties,  rather  than  going  di¬ 
rectly  to  qualifying  jurisdictions,  including  cities. 

♦  DHS  priorities  are  often  not  the  priorities  of  the  local  jurisdictions. 

♦  The  priorities  of  counties  and  subcounty  jurisdictions  may  differ. 

Local  jurisdictions  believe  they  fulfill  the  requirement  for  shared  responsibility 
for  funding  through  the  emergency  services  they  provide  day-to-day,  such  as 
police,  fire,  and  medical  services.  They  believe  the  cost  of  such  services  should 
represent  their  match  for  federal  funding,  allowing  them  to  more  adequately  and 
fairly  fund  an  EM  program  that  would  meet  jurisdictional  priorities,  as  well  as 
those  for  a  nationwide  planning,  preparedness,  and  response  capability.  As  it 
stands,  the  benefits  of  receiving  federal  funding  can  be  outweighed  by  the 
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matching  funds  requirement  and  the  amount  of  time  and  effort  required  to  keep  up 
with  the  administrative  work.  In  addition,  a  common  issue  stated  by  city  represen¬ 
tatives  was  that  funding  should  come  to  them  directly  without  being  diminished 
by  being  fdtered  through  the  state  and  the  county.  One  drawback  to  doing  so  is 
that  coordination  among  jurisdictions  and  levels  of  government  is  less  likely  to 
take  place. 

Federal  funding  regulations  also  significantly  affect  the  acquisition  and  use  of 
computer  tools,  due  to  the  lack  of  the  following: 

♦  Leadership  in  establishing  equipment  and  software  standards  for  interop¬ 
erability 

♦  Standards  for  evaluating  software  applications 

♦  Funding  for  ongoing  training 

♦  Funding  for  maintenance  costs 

♦  Funding  for  database  development 

♦  Funding  for  proficient  IT  personnel. 

On  the  local  level,  major  technology  purchases  are  often  not  considered  priority 
expenditures  when  compared  with  other  types  of  ES  equipment.  Interviewees 
identified  the  need  for  funding  for  the  following  items: 

♦  Computer  technology 

>  Establishing  a  process  to  support  IT  capital  investment  planning 

>  Establishing  interoperability  standards 

■  Equipment 

■  Software  (GIS,  models,  tools) 

>  Training 

>  Maintaining  equipment 

>  Obtaining  and  retaining  qualified  IT  personnel 

♦  Planning 

>  Preparing  for  low-probability /high-impact  national  security  threats 
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>  Preparing  for  catastrophic  events  beyond  the  response  capabilities  of 
the  local  jurisdiction1 

♦  Exercises 

>  Back-filling  positions  so  responders  can  leave  their  posts  to  participate 
in  exercises 

>  Planning,  conducting,  and  evaluating  exercises 

♦  Training 

>  Back-filling  positions  so  responders  can  attend  training 

>  Sending  personnel  to  training  opportunities  related  to  both  national 
and  jurisdictional  program  requirements. 

Education  and  Training 


The  EM  field  will  continue  to  evolve  as  more  and  more  sophisticated  models, 
tools,  and  software  become  available  for  EM  and  ES  personnel  to  utilize  for  day- 
to-day  preparation  as  well  as  for  emergency  response.  Interviewees  mentioned  a 
wide  spectrum  of  issues  related  to  developing  and  sustaining  computer  skills,  es¬ 
tablishing  a  mentoring  program  to  ensure  smooth  succession,  maintaining  corpo¬ 
rate  memory,  and  so  on. 

An  important  need  stated  by  interviewees  was  more  education  and  training  not 
only  in  available  models  and  other  software,  but  also  regularly  scheduled  training 
and  routine  refresher  courses.  Many  people  said  that  even  if  good  software  is 
available  and  accessible,  it  may  not  be  used  routinely.  Therefore,  users  may  not 
retain  the  information  on  how  to  use  the  software  and  may  not  have  the  profi¬ 
ciency  to  use  it  when  needed  for  emergency  response. 

The  following  are  other  operational  requirements  identified  by  interviewees: 

♦  Multiple  modes  of  training  delivery  (video,  web,  self-service,  e-leaming) 
so  that  anyone  can  take  a  course  anytime,  anywhere 

♦  Detailed  software  manuals  with  screenshots  and  summary  “cheat  sheets” 
to  guide  users 

♦  “Train- the-trainer”  approach  and  routine  in-house  training  for  important 
courses. 


1  Local  jurisdictions  are  generally  able  to  respond  to  and  manage  major  disaster  events.  How¬ 
ever,  low-probability /high-impact  threats  would  require  significant  external  state  and  federal  re¬ 
sources  to  ensure  an  initial  response  capability. 
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FEMA  has  many  training  courses  in  all  areas  of  emergency  management  and  for 
various  emergency  response  disciplines,  and  it  provides  access  to  many  educa¬ 
tional  tools  such  as  the  Joint  Information  Center.  Interviewees  expressed  support 
for  FEMA  to  establish  more  agreements  with  educational  institutions,  such  as 
community  colleges,  for  training  and  education,  with  arrangements  to  waive  or 
discount  tuition.  Interviewees  also  suggested  that  FEMA  invest  more  in  alterna¬ 
tive  ways  for  learning,  such  as  more  training  delivered  electronically,  via  the  web, 
and  through  learning  media  such  as  CDs  and  online  classes. 

Other  training  and  educational  requirements  include  the  need  for  jurisdictions  to 
train  together  to  prepare  for  a  multi -jurisdictional  or  interstate  response.  Inter¬ 
viewees  often  stated  that  not  enough  planning  goes  into  a  multi-jurisdictional  re¬ 
sponse;  instead,  personnel  must  rely  on  past  experience  as  the  way  to  prepare  for 
a  response.  The  need  for  planning  and  coordination  is  paramount,  particularly 
considering  the  variety  of  potential  events  (chemical,  biological,  terrorist,  natural 
disaster,  etc.).  If  jurisdictions  plan  together,  they  can  also  coordinate  to  share  per¬ 
sonnel  and  resources  and  to  exchange  ideas  and  best  practices.  ES  personnel  also 
need  a  model  to  transfer  the  knowledge  of  senior  or  retiring  personnel  to  their  ES 
successors,  in  the  form  of  a  mentoring  program  or  specific  classes  to  address  suc¬ 
cession  planning  and  retention  of  corporate  memory. 

Interviewees  expressed  the  need  for  training  to  be  expanded  to  include  cross¬ 
training  for  ES  personnel,  which  they  said  would  be 
ideal  for  multi-jurisdictional  training  classes.  They 
indicated  they  want  state  and  federal  agencies  to  offer 
more  sophisticated  types  of  training  such  as  role- 
based  or  “virtual”  training.  Other  requirements  in¬ 
clude  having  a  model  for  a  more  robust  training  pro¬ 
gram  that  provides  for  regularly  scheduled  (monthly, 
for  example)  training  and  refresher  courses,  including 
“networked”  and  live  video  training  for  geographi¬ 
cally  dispersed  groups. 

Availability  of  funding  is  one  of  the  biggest  obstacles  to  a  robust  training  pro¬ 
gram: 

♦  Insufficient  funds  are  allocated  and  budgeted  for  training. 

♦  Not  all  pertinent  and  necessary  training  can  be  accommodated,  requiring 
that  training  needs  be  prioritized  and  severely  restricted  even  though  many 
personnel  need  training. 

♦  ES  organizations  are  not  able  to  provide  personnel  with  the  training 
needed  to  build  up  the  emergency  management  and  response  capabilities. 


Training 

Training  requirements  in¬ 
clude  the  need  for  different 
training  delivery  options, 
better  manuals,  cross¬ 
training  of  personnel,  suffi¬ 
cient  funding,  and  IT  train¬ 
ing  in  both  software 
acquisition  and  computer 
applications. 
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Resolution  of  these  issues  is  considered  operationally  essential  to  an  effective  EM 
organization.  The  following  are  some  specific  operational  requirements: 

♦  Training  in  functional  evaluation  and  analysis  of  software 

♦  Training  in  methods  and  benefits  to  using  computer  tools  day-to-day  and 
during  an  event  (continuous) 

♦  Training  in  understanding  barriers  to  interstate  response  and  developing 
procedures  for  working  together  across  state  lines 

♦  Implementable  methods  to  ensure  adequate  opportunities  for  personnel  to 
receive  essential  training 

♦  Implementable  methods  to  promote  cross-training  among  response  per¬ 
sonnel 

♦  Routine  ongoing  in-house  training. 
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Chapter  4 

Conclusions 


The  role  of  the  ES  community  is  unique  for  a  number  of  reasons.  Its  performance 
needs  to  be  at  its  strongest  when  the  supporting  infrastructure  is  at  its  weakest  or 
even  nonexistent.  It  has  diverse  responsibilities  and  component  organizations  at 
all  jurisdictional  levels  that  must  operate  in  a  coordinated  and  cooperative  manner 
in  order  to  be  effective.  In  addition,  the  jurisdictions  in  this  community  face 
unique  challenges  related  to  communicating  and  sharing  information  with  other 
jurisdictions  and  the  public,  both  when  preparing  for  and  responding  to  an  event, 
as  well  as  when  recovering  from  an  event.  Their  work  is  further  complicated  by 
privacy,  political,  and  social  issues. 

The  ES  community  is  using  a  wide  variety  of  tools  to  facilitate  event  preparation 
and  response.  For  example,  many  jurisdictions  have  software  to  capture,  store, 
track,  and  disseminate  information.  They  also  use  numerous  manual  tools  such  as 
guidebooks,  checklists,  and  Excel  spreadsheets.  However,  these  models  and  tools 
are  not  sufficiently  robust  to  support  the  modeling,  simulation,  and  analysis  that 
are  crucial  to  ensuring  the  most  efficient  and  effective  response  to  an  event. 
Moreover,  they  are  rarely  integrated,  either  across  ES  disciplines  or  across  juris¬ 
dictions  at  all  levels. 

To  best  prepare  for  and  respond  effectively  and  efficiently  to  an  event  at  the  state 
and  local  levels,  the  ES  community  needs  better  models  and  other  tools.  In  addi¬ 
tion,  all  models  and  tools  must  support  national  assessments  of  preparedness  and 
readiness  as  articulated  in  the  15  NPSs. 

The  functional  requirements  we  identified  are  high-level,  core  areas  of  functional¬ 
ity  that  the  ES  community  considers  necessary  in  any  model  or  tool  they  might 
use  to  prepare  for,  respond  to,  and  recover  from  an  emergency.  The  following 
functional  requirements  are  key: 

♦  Models  and  tools  to  support  modeling  for  the  15  NPSs  should  be  provided 
to  all  jurisdictions  by  DHS. 

♦  Models  and  supporting  tools  should  accept  inputs  from,  and  outputs  to, 
commonly  available  software  such  as  the  Microsoft  Office  suite  of  prod¬ 
ucts. 

♦  Jurisdictions  need  a  process  to  integrate  model  and  tool  use  into  everyday 
operations. 

♦  To  maintain  continuity  of  operations,  software  must  look  and  operate  the 
same,  regardless  of  mode:  networked,  LAN  only,  or  standalone  laptop. 
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♦  Software  must  integrate  with  other  applications  easily,  scale  up,  and  use 
familiar  tenninology,  for  support  by  nontechnical  emergency  personnel. 


♦  Adoption  and  implementation  of  software  must  be  possible  for  both  well- 
funded  jurisdictions  and  jurisdictions  with  no  overhead  funds. 

♦  Maintenance  of  software  must  be  very  low  cost  and  require  minimal  tech¬ 
nical  skills  from  using  jurisdictions. 

♦  Asset  management  tools  must  exchange  data  using  some  common,  easy- 
to-use,  and  low-cost  or  no-cost  standard  or  format. 

♦  Software  must  include  more  than  the  technical  information  needed  to  im¬ 
plement  it.  Jurisdictions  need  infonnation  on  different  implementation 
paths  and  tools  (such  as  checklists)  to  help  them  plan  for,  deploy,  and  sup¬ 
port  software. 

♦  Jurisdictions  need  models  to  support  three  types  of  risk  analyses:  overall 
risk  assessments,  in-depth  analyses  of  high-risk  hazards  and  threats,  and 
analyses  of  low-probability/high-impact  threats. 

DHS/S&T  needs  to  define  the  functional  requirements  in  more  detail  and  then 
identify  the  specific  technical  requirements  for  modeling,  simulation,  and  analy¬ 
sis. 

The  operational  requirements  we  identified  address  items  that  are  not  directly 
linked  to  one  specific  module  or  specific  requirement,  but  are  nonetheless  essen¬ 
tial  to  the  deployment  and  adoption  of  any  of  the  pieces  of  the  overall  system. 
Generally,  the  operational  requirements  represent  barriers  that  hamper  the  ability 
of  almost  all  jurisdictions  to  adopt  new  models  and  tools,  although  the  impact  var¬ 
ies  depending  on  factors  such  as  location,  population,  executive  support,  and 
structure  and  size  of  the  emergency  services  organization.  In  most  cases,  some  of 
the  operational  requirements  must  be  satisfied  to  implement  software  models  and 
tools.  Otherwise,  the  models  and  tools  cannot  be  adopted,  maintained,  and  used. 
The  following  are  key  operational  requirements: 

♦  Approaches  and  methods  to  easily  and  effectively  engage  all  planning  and 
general  information  sharing  across  all  disciplines 

♦  Guidance  at  the  federal,  FEMA  region,  state,  and  local  levels  on  data  and 
information  sharing 

♦  An  integrated  process  to  define  the  roles  of  the  disciplines,  the  key  respon¬ 
sibilities,  and  both  the  shared  and  the  role-specific  privileges  of  operations 
management  software 

♦  Decision  support  information  from  a  trusted  source  in  the  ES  community 
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Conclusions 


♦  An  authoritative  source  for  guidance  and  standards  in  effect  and  a  regular 
review  process  to  ensure  that  they  remain  viable  and  up  to  date 

♦  At  the  federal  level,  clear  differentiation  between  what  should  be  regarded 
as  “guidance”  and  what  constitutes  “standards” 

♦  Flexible,  adaptable,  and  changeable  processes  for  use  by  jurisdictions  dur¬ 
ing  both  preparation  for  and  response  to  an  event 

♦  Policies  that  support  collaborative  planning,  risk-based  funding,  and  proc¬ 
esses  or  methods  to  resolve  inter-jurisdictional  differences  of  opinion  and 
to  address  political  issues. 

The  operational  requirements  reveal  that  more  than  a  suite  of  models  is  needed. 
The  ES  community  cannot  adopt  models  and  other  software  tools  without  a 
number  of  types  of  support  including,  for  example,  processes  for 

♦  determining  which  models  they  need,  finding  and  selecting  the  right 
supporting  software,  and  planning  for  and  executing  the  software  and 
model  implementation; 

♦  determining  the  full  life-cycle  cost  of  a  software  implementation  (whether 
a  model  or  supporting  software)  and  for  capital  planning  or  other  ways  of 
funding  the  implementation;  and 

♦  contacting  peers  who  operate  in  a  similar  environment  (services  provided, 
population  served,  funding  limits,  hazards)  and  have  successfully 
implemented  models  or  software  tools. 

DHS/S&T  needs  to  address  the  operational  requirements  within  its  purview. 
However,  some  of  these  requirements  can  be  addressed  only  by  other  organiza¬ 
tions  within  DHS.  S&T  should  partner  with  those  organizations  to  ensure  that  the 
operational  requirements  are  fully  addressed.  These  partnerships  are  critical,  be¬ 
cause  some  operational  requirements  must  be  met  if  DHS  is  to  overcome  the  bar¬ 
riers  to  the  adoption  of  modeling,  simulation,  and  analysis  tools  by  the  entire  ES 
community. 
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Appendix  A 

Software  and  Other  Tools 


Table  A-l  lists  the  software  and  other  tools  being  used  by  the  emergency 
management  community.  For  each  item  listed,  it  shows  the  jurisdictions  in  our 
sample  that  use  the  software  or  tool,  by  population  range. 

Table  A-1.  Commercial  Software 


Item 

1- 

14,999 

15,000- 

49,999 

50,000- 

99,999 

100,000- 

249,999 

250,000- 

499,999 

500,000- 

999,999 

1,000,000- 

4,999,999 

Over  5 
million 

Statewide 

ACAMS/FEMA 

1  tribe 

1  city 

1  state 

AEGIS  (Records 
Management  System) 

1  city 

1  city 

Aid-Matrix/FEMA 

1  NGO 

Alert-Find/Message  One 

1  NGO 

Alliance  Systems  CAD 

1  county 

ALOHA 

1  county 

2  counties 

1  county 

2  cities 

1  county 

1  state 

AMANDA3 

1  city 

ArcView  Suite 

1  county 

1  tribe 

1  county 

2  counties 

5  cities 

2  counties 

1  tribal 
consortium 

2  counties 

1  city 

2  cities 

1  NGO 

7  states 

Automated  Flood 

Warning  System/NWS 

1  city 

1  city 

BaseCamp 

1  city/M  MRS 

Bio-Surveillance 

1  city 

BlO-Watch 

2  cities 

1  city 

Biz  Recovery 

1  city 

BREEZE-VOIP 

1  city 

BROOM 

1  city 

CAD 

1  county 

2  counties 

CAD-Alliance 

1  county 

California  Law 
Enforcement  Technology 
Systems3  (CLETS) 

1  county 

CAMEO 

1  tribe 

2  counties 

1  county 

2  cities 

1  county 

1  county 

1  city 

2  states 

Catastrophic  Assessment 
Tool  Set 

2  cities 

1  tribe 

CDC-Epi 

1  city 

CDC-FluAide 

1  county 

CERT-FEMA 

1  county 
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Item 

1- 

14,999 

15,000- 

49,999 

50,000- 

99,999 

100,000- 

249,999 

250,000- 

499,999 

500,000- 

999,999 

1,000,000- 

4,999,999 

Over  5 
million 

Statewide 

Chemical  Reactivity 
Worksheet 

1  county 

1  city 

City  Watch  /AvTex 

1  county 

1  county 

City  Watch/ AvTex 

1  county 

1  county 

CODE  RED 

1  county 

Common  Alerting 

Protocol 

1  state 

Continuity  of 
Government/Strohl’s 

1  county 

Coordinated  Assistance 
Network 

1  NGO 

CrimeView/Omega 

1  county 

D2PUFF 

1  county 

DeLorme 

1  state 

DisasterLan  Buffalo 
Computer  Graphics 

1  city 

2  states 

DMIS 

1  city 

1  state 

DROMIS/FEMA/ARC 
Disaster  Relief 

Operations  System 

1  NGO 

Electronic  Patient 
Tracking  System  (EPTS) 
(Raytheon) 

1  city 

EMCAPS 

1  county 

EM  Constellation 

1  NGO 

Emergency  Management 
Information  Tracking 
System  (EMITS) 

1  state 

Emergency  Notification 
System/Purvis 

1  city 

EmerGEO 

1  state 

EMNet 

1  state 

EMSystems 

1  city 

Epi-lnfo  CDC 

1  county 

E-Plan/HazMat 

1  city 

E-Team 

2  counties 

2  cities 

1  city 

1  NGO 

FDM  Records 
Management  System 
and  CAD  products 

1  city 

FEMIS  (free,  but  requires 
Oracle  and  other 
commercial  products) 

1  county 

1  state 

Fire  House 

1  city 

1  county 

Fire  View/Omega 

1  county 
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Table  A-1.  Commercial  Software 


Item 

1- 

14,999 

15,000- 

49,999 

50,000- 

99,999 

100,000- 

249,999 

250,000- 

499,999 

500,000- 

999,999 

1,000,000- 

4,999,999 

Over  5 
million 

Statewide 

Fire  base 

1  city 

Fi  re-CAD 

1  city 

First-Watch 

1  city 

FluSurge  2.0/CDC 

1  city 

Google  Maps/Virtual 

Earth 

1  county 

1  city 

1  tribe 

2  cities 

1  city 

1  county 

1  NGO 

2  states 

Han-Soft 

1  county 

HAZUS 

1  city 

1  tribe 

1  city 

2  cities 

6  states 

HC-Standard 

1  city 

Health  Information 
Research  Management 

1  county 

HSEEP  TOOLKIT 

1  county 

2  counties 

2  counties 

3  cities 

2  cities 

2  cities 

1  county 

3  states 

HSEEP/N  (NXS) 

1  city 

1  city 

1  state 

HSEEP/National  Shelter 
System  (NSS) 

1  state 

HTE’s  CAD 

1  county 

HurrEvac 

1  city 

1  city 

1  city 

1  NGO 

1  state 

1-Link 

1  county 

IPAWS 

1  state 

LARCOP 

1  county 

Law  Enforcement  Online 
(LEO) 

1  county 

1  city 

Living  Disaster  Recovery 
Planning  System — 
STROHL 

1  state 

Locally  Developed 
Software 

1  city 

1  county 

1  city 

1  county 

3  states 

Lotus  Notes  Suite 

1  NGO 

MABAS.ORG 

1  county 

MarPlot 

2  counties 

2  cities 

Maximo 

1  county 

1  city 

Medical  Surge 

1  city 

Medicom 

1  city 

Microsoft  Access 

1  tribe 

1  state 

Microsoft  ASP.net 

1  state 

Microsoft  Live 

1  state 

Microsoft  Office  Suite 

2 

counties 

1  county 

1  county 

3  cities 

1  tribe 

3  cities 

2  counties 

1  city 

1  city 

1  NGO 

1  county 

1  NGO 

3  states 

Microsoft  Sequel  Server 

2  states 

Microsoft  SharePointe 

1  city 

1  tribe 

1  city 
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Item 

1- 

14,999 

15,000- 

49,999 

50,000- 

99,999 

100,000- 

249,999 

250,000- 

499,999 

500,000- 

999,999 

1,000,000- 

4,999,999 

Over  5 
million 

Statewide 

Microsoft  Systems 
Essentials  2007 

1  state 

Mir3 

1  county 

National  Weather  Service 
products  (NWS) 

1  county 

1  county 

1  city 

1  tribe 

1  city 

NEMIS 

1  state 

New  World 

1  city 

1  county 

NIMS-Cast 

1  city 

1  tribe 

1  county 

1  city 

1  state 

North  Carolina-State 
Medical  Asset,  Resource 
Tracking  (NC-SMART) 

1  county 

1  state 

OASIS 

1  city 

Orbit  One 

1  NGO 

PassagePoint 

1  NGO 

Pictometry  viewing 
capability 

1  city 

Planning  for 

Fires/Omega 

1  county 

Pre  Hospital  Medical 
Information  System 

1  county 

Property  Appraiser 
Records 

1  NGO 

PS-NET 

1  city 

Purvis  Systems 

1  city 

Q-T  Modeler 

1  state 

Rapid  Responder® 
Prepared  Response,  Inc. 

1  city 

RazrWire 

1  city 

Ready.gov  FEMA 

1  county 

1  city 

1  tribe 

1  city 

1  city 

Ready-Net 

1  city 

Resource  Manager 

1  city 

Reverse  91 1 

1  city 

2  cities 

2  counties 

2  cities 

1  state 

RevEX/Trifolium 

1  state 

Riverine-FEMA 

1  state 

SATERN.org 

1  NGO 

SDN  Global 

1  NGO 

SLOSH 

1  city 

1  state 

Smart-PH 

1  tribe 

Spillman 

1  county 
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Table  A-1.  Commercial  Software 


Item 

1- 

14,999 

15,000- 

49,999 

50,000- 

99,999 

100,000- 

249,999 

250,000- 

499,999 

500,000- 

999,999 

1,000,000- 

4,999,999 

Over  5 
million 

Statewide 

Star  Room 

1  city 

Sync  Matrix 

1  city 

Synergen 

1  county 

Telestaff/PDSI 

1  city 

1  state 

TetroTech  (Gray  Prgs) 

1  state 

Tiger  Census  Data 

3  cities 

1  tribe 

ToughBooks 

1  county 

Trimble  GPS 

1  tribe 

T-Soft 

2  cities 

1  state 

U-Call/V-Call 

1  city 

1  state 

WARN 

1  county 

1  county 

Weather  Sentry-DTN 
Weather  Service 

1  city 

WebEOC 

2  counties 

2  counties 

5  cities 

1  county 

1  tribe 

2  counties 

2  cities 

7  states 

Web-Fusion/ESI 

1  state 

Wind  SpeedUp  Model 

1  county 

World  Wind/NASA 

1  tribe 

1  tribe 

1  state 

Wyo-Linka 

1  county 

1  county 

Note:  MMRS  =  Metropolitan  Medical  Response  System;  NGO  =  non-governmental  organization;  NWTEMC  =  North  West  tribal  Emergency 
Management  Council/Consortium. 

a  Developed  by,  and  free  to,  USACE  users;  for  non-USACE  users,  most  models  must  be  obtained  from  commercial  sources. 
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Appendix  B 

Functional  Requirements 


This  appendix  lists,  in  Table  B-l,  the  functional  requirements  identified  by  our 
interviewees.  The  requirements  are  grouped  into  the  following  categories: 

♦  General  technology 

♦  Models 

♦  Tools 

♦  Tool  integration 

♦  Data. 


Table  B-1.  Functional  Requirements 


Category 

Requirement 

General 

technology 

Jurisdictions  need  federally  supplied  tools  and  plans  to  accommodate  well-funded  and  minimally 
funded  jurisdictions. 

Jurisdictions  need  to  have  access  to  tools/computer  modeling  that  would  help  them  better  pre¬ 
pare  for  response. 

Jurisdictions  need  to  factor  in  maintenance  costs  when  deciding  what  tools  to  utilize  for  planning 
and  response,  as  many  jurisdictions  do  not  have  the  in-house  capability  to  handle  management 
and  maintenance  of  the  systems  and  can’t  afford  to  get  it. 

Jurisdictions  need  Emergency  Management  systems  (ex:  WebEOC),  that  are  implemented  by 
the  State,  to  provide  adequate  access,  training,  licensure,  version  compatibility,  and  interopera¬ 
bility  across  platforms  and  applications  commonly  in  use. 

Jurisdictions  need  capabilities  similar  to  Virtual  Alabama. 

Jurisdictions  need  tools  that  have  asset  tracking  capabilities  to  exchange  warehouse  information 
on  available  resources. 

Jurisdictions  need  tools  that  have  asset  tracking  capabilities  to  perform  resource  tracking,  in¬ 
cluding  ‘typing’  according  to  DHS  requirements. 

Jurisdictions  need  tools  that  have  logistics  and  resource  management  capabilities. 

Jurisdictions  need  tools  that  have  asset  tracking  capabilities  to  perform  asset  visibility  and  track¬ 
ing  for  people  and  other  resources. 

Jurisdictions  need  tools  and/or  models  to  work  for  everyday  operations,  and  scale  up  or  down  to 
support  the  size  of  the  incident. 

Jurisdictions  need  a  real-time  dependable  asset  accountability  system. 

Jurisdictions  need  access  to  non-emergency  event  management  software  and  modeling  in  order 
to  gain  proficiency  in  the  use  of  these  tools  for  emergencies. 

Jurisdictions  need  technology  tools  that  are  sufficiently  intuitive,  easy  to  learn,  and  user  friendly 
to  allow  effective  utilization. 

B-l 
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Table  B-1.  Functional  Requirements 


Jurisdictions  would  like  a  database  of  hotels/motels/visitor  accommodations  could  be  used  as 
emergency  short  term  shelters. 


Jurisdictions  need  a  real  time  capability  to  identify  the  availability  of  resources  needed  by  a 
jurisdiction  that  could  be  provided  by  a  neighboring  jurisdiction  or  outside  resources. 

Jurisdictions  need  a  tool  that  will  capture  information  from  the  Pacific  Disaster  Warning  Cen¬ 
ter/Pacific  Tsunami  Warning  Center,  NOAA,  Universities,  U.S.  Forest  Service,  State  Forestry, 
Weather  Service,  etc. 

Jurisdictions  would  like  to  go  to  a  central  location  to  see  tools  that  everyone  else  is  using,  as 
well  as  to  see  what  type  of  access  exists  for  these  tools. 

Jurisdictions  need  a  centralized  repository  for  plans  and  planning  documentation. 

Jurisdictions  would  like  to  have  tools  to  estimate  resource  requirements. 

Jurisdictions  would  like  a  tool  for  all-hazards  planning;  generally  in  the  form  of  detailed  and  com¬ 
prehensive  checklists,  which  would  prompt  the  user  with  questions  and  best  practices. 

Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  to  special  popula¬ 
tions,  and  also  an  application  (maybe  self-service)  to  let  ‘special  needs’  populations  voluntarily 
register  (non-English  speakers,  mobility  impaired,  etc.). 

Jurisdictions  would  like  tools  to  let  ‘special  needs’  populations  voluntarily  register  (non-English 
speakers,  mobility  impaired,  etc.). 

Jurisdictions  would  like  a  tool  that  has  pre-planning  information,  such  as  certain  types  of  ad¬ 
dresses  and  occupancies. 

Jurisdictions  need  a  tool  to  publish  self-help  information  in  Phonebooks  for  visitors  and  residents 
for  personal  planning  and  response  to  potential  local  emergency  threats. 

Jurisdictions  need  a  central  repository  for  database  layers,  which  can  be  fully  accessed  at  the 
EOC,  to  provide  data  and  tools  for  risk  analysis,  deployment  and  tracking  available  resources, 
situational  awareness,  as  well  as  the  preparation  of  reports  and  briefings. 

Jurisdictions  would  like  a  central  repository  to  document  exercises  and  simulations  based  on 
information  in  other  systems  such  as  WebEOC;  capture  and  retrieve  after-action  reports  (AARs) 
and  lessons  learned  documentation. 

Jurisdictions  need  tools  that  provide  locations  for  points  of  distribution  (for  resources,  supplies); 
a  tool  to  better  manage  regional  response  assets. 

Jurisdictions  would  like  a  tool  that  provides  state-wide  GIS  capabilities,  such  as  “Virtual  Ala¬ 
bama”,  and  contains  information  on  who  owns  the  land  and  populated  areas,  and  property  line 
information. 

Jurisdictions  would  like  the  ability  to  identify  response  capabilities  and  resource  location. 

Jurisdictions  would  like  to  have  a  tool  that  can  capture  specific  information  about  events,  which 
can  then  be  shared  among  response  agencies.  Therefore,  providing  a  central  repository  for  in¬ 
formation  about  any  event. 

Jurisdictions  need  modeling  capabilities  for  post-event  analysis  and  data  capture  (for  example, 
to  survey  public  officials  about  what  worked/didn’t  work). 

Jurisdictions  need  resource  databases  are  needed  for  deployment  and  tracking,  and  which  can 
be  viewed  real-time  during  an  event. 

Jurisdictions  need  grants  to  cover  scheduling  tools  and/or  software. 

Jurisdictions  need  grants  to  cover  command  and  control  technology  for  tracking  vehicles  and 
personnel. 

Jurisdictions  need  grants  to  cover  MDT’s. 
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Jurisdictions  need  grants  to  cover  satellite  communications  that  would  ensure  redundancy. 


Jurisdictions  need  video  streaming  capability  for  interoperability. 

Jurisdictions  would  like  to  have  regular  notifications  and  alerts  from  forestry  agencies  and  ac¬ 
cess  to  details  about  any  forestry-related  events,  with  drill-down  to  detail. 

Jurisdictions  would  like  a  tool  that  provides  inventory  management  capabilities. 

Jurisdictions  need  tools  for  expedient  evaluation  of  event  results. 

Jurisdictions  would  like  tools  that  enable  barcode  and  scanner-enabled  material  management. 

Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  to  the  public. 

Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  both  static  and 
dynamic/real-time  to  the  public 

Jurisdictions  would  like  tools  that  have  asset  tracking  capabilities. 

Jurisdictions  would  like  a  tool  that  tracks  responders  within  buildings  (underground?). 
Jurisdictions  would  like  tools  for  video  conferencing. 

Jurisdictions  would  like  a  web-based  system  for  tracking  volunteers-interactive  for  the  volunteer 
to  self  enter  data;  a  self-service  application. 

Jurisdictions  would  like  a  tool  to  track  donations. 

Jurisdictions  would  like  a  tool  to  track  requests  for  assistance. 

Jurisdictions  need  a  way  to  track  expenditures  for  public  works  departments. 

Tool  Jurisdictions  would  like  the  ability  to  process  and  produce  an  interoperable  system  acceptable 

integration  across  IT  departments  as  well  as  EOCs. 

Jurisdictions  would  like  the  ability  to  identify  the  availability  and  prioritization  of  applica¬ 
tions/programs  suitable  for  integration  with  a  variety  of  products  such  as  the  ArcView  suite. 

Jurisdictions  would  like  the  ability  to  communicate  and  share  information  with  communities  of 
similar  size  and  resources  in  order  to  stay  abreast  of  best  management  practices. 

Jurisdictions  would  like  tools  need  to  be  developed  using  a  flexible,  open  architecture  in  order  to 
work  across  systems  and  hardware. 

Jurisdictions  would  like  a  tool  to  tie  in  information  and  form  data  between  the  local  emergency 
management  folks,  FEMA,  the  localities,  and  the  State  (while  also  taking  into  account  the 
Budget,  funding,  thresholds,  etc.),  and  then  navigate  the  bureaucratic  paperwork  and  workflow. 

Jurisdictions  would  like  network  capability  to  involve  all  satellite  locations  for  training. 

Jurisdictions  want  the  ability  to  wirelessly  integrate  CAD  data  with  field  assessments  to  assign 
and  track  activities  and  progress  of  cleanup/recovery  crews. 

Jurisdictions  would  like  a  standard  interoperable  tool  suite  that  will  interoperate  at  all  population 
levels. 

Jurisdictions  would  like  a  standard  interoperable  tool  suite  that  extend  beyond  communications, 
should  apply  to  all  systems  and  all  disciplines. 

Jurisdictions  would  like  a  standard  interoperable  tool  suite  that  should  have  the  ability  to  plug 
and  play. 

Jurisdictions  would  like  a  standard  interoperable  tool  suite  that  interact  real  time  during  an  event, 
as  well  as  day-to-day. 

Jurisdictions  need  larger  jurisdictions  to  encourage  the  virtual  participation  of  smaller  jurisdic¬ 
tions  in  the  daily  use  of  EOC  software  to  share  perspectives  on  planning  and  response  require¬ 
ments. 
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Jurisdictions  need  to  integrate  all  the  information  needed  to  address  all  critical  elements  required 
for  event  management. 


Jurisdictions  need  a  nationwide  standard  for  Emergency  Management  taxonomy  and  data  ex¬ 
change  so  that  various  tools/software  can  transmit  data  between  different  tools  created  by  dif¬ 
ferent  vendors  (or  for  tools  developed  in-house.) 

Jurisdictions  need  FEMA  regions  to  support  and  standardize  on  either  specific  software  applica¬ 
tions  (ex:  WebEOC)  or  on  critical  data  exchange  functions  commonly  in  use  throughout  their 
Region. 

Jurisdictions  need  states  to  ensure  local  accessibility  and  stable  communication  links  for  appli¬ 
cations  [such  as  WebEOC]  which  they  have  installed  and  implemented. 

Jurisdictions  need  tools  and  models  to  integrate  data  capture  and  use  for  exercise  simulation 
and  documentation. 

Jurisdictions  need  storm  surge  data  that  can  be  overlaid  on  flood-zone  maps  and  then  inte¬ 
grated  w/reverse  911  information. 

Jurisdictions  need  to  integrate  plume  data  in  CAMEO  with  the  GIS  system  and  reverse  91 1 . 
Jurisdictions  need  data  pertaining  to  EPA  Tier  II,  or  Hazmat. 

Jurisdictions  would  like  the  capability  to  integrate  surveillance  and  command/control  functions 
into  a  single  portal  for  pandemic  flu. 

Jurisdictions  need  WebEOC  to  link  to  not  only  counties,  but  also  to  cities. 

Jurisdictions  would  like  systems  to  connect  to  integral  nongovernmental  components  of  emer¬ 
gency  response  such  as  the  American  Red  Cross. 

Jurisdictions  would  like  the  capability  to  integrate  data  across  all  tools,  not  just  GIS:  could  be 
standards  driven  or  could  be  a  separate  application  tool  (UDEF). 

Jurisdictions  need  tools  that  have  asset  tracking  capabilities  need  to  be  consistent  with 
DHS/NIMS  and  WebEOC. 

Jurisdictions  would  like  tools  to  capture  data  at  the  finest  level  of  granular  detail,  to  support  later 
aggregation  of  the  data  in  various  ways,  such  as:  all  pertinent  post-incident  data  to  prepare  a 
Governor’s  request  to  the  President  for  a  disaster  declaration  which  would  provide  for  cost  re¬ 
covery.  (Post  Event  Accounting) 

Jurisdictions  need  EOCs  to  see  what  another  EOC  in  its  jurisdiction/county/state/region  is  see¬ 
ing,  for  example  real-time  visual  links  and  data  uploads/downloads,  video  streaming,  etc. 

Jurisdictions  need  WebEOC  to  exchange  information  and/or  have  compatibility  between  ver¬ 
sions. 

Jurisdictions  need  data  that  is  easy  to  integrate  on  simulated  maps  (Virtual  Alabama  is  an  ex¬ 
ample  of  this). 

Jurisdictions  need  to  integrate  facility  plans  for  buildings  with  GIS. 

Jurisdictions  would  like  a  tool  that  provides  a  live  feed  into  emergency  dispatch  center  with 
POCs  for  each  location  in  an  event. 

Jurisdictions  need  clear  guidelines  for  electronic  tracking  of  resource  expenditures  for  all  re¬ 
sponse  agencies. 
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Table  B-1.  Functional  Requirements 


Category  Requirement 

Data  Jurisdictions  need  to  retain  “historic”  data  for  specific  response  activities  to  use  in  estimating 

future  response  needs. 

Jurisdictions  need  to  have  a  Resource  Tracking  and  Situational  Awareness  tool  with  the  caveat 
that  each  entity  only  sees  their  own  info,  but  can  be  fully  accessed  at  the  EOC. 

Jurisdictions  need  a  common  EM  data  standard,  nor  a  process  for  exchanging  data. 

Jurisdictions  need  a  common  operating  capability  for  exchanging  data-county  to  county/county 
to  state/state  to  state,  and  so  on.  They  would  like  FEMA  to  take  the  lead  in  addressing  this  need 

Jurisdictions  need  local  EMAs  to  access  continuous  critical  data,  such  as  weather  information, 
that  would  assist  them  in  planning  and  responding  effectively. 

Jurisdictions  need  standard  data  to  describe  the  resources  needed  real  time  during  an  event. 

Jurisdictions  would  like  a  clearinghouse  for  EM  data:  casualties  under  scenarios,  etc. 

Jurisdictions  need  field  collection  of  data  is  needed  for  analysis  for  planning. 

Jurisdictions  need  weather  information  to  not  be  localized  and  available  more  than  just  Monday 
through  Friday  via  state  systems. 
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Appendix  C 

Use  of  the  Vulnerability  Analysis  Chart 


FEMA  designed  the  Vulnerability  Analysis  Chart  to  assist  jurisdictions  with  pri¬ 
oritizing  resources  according  to  the  potential  risk.  This  appendix  describes  how 
the  Vulnerability  Analysis  Chart  is  used. 

Table  C-l  is  an  example  using  the  matrix  to  provide  an  estimation  of  potential 
vulnerability  to  common  threats: 

♦  “Probability”  and  “Impacts”  are  rated  on  a  scale  of  1  to  5,  with  1  being 
low  and  5  being  high;  0  indicates  no  risk. 

♦  “Capability”  is  also  rated  on  a  scale  of  1  to  5,  with  1  being  the  best  (the 
lower  the  number,  the  greater  the  capability  is  to  respond,  thus  reducing 
the  risk). 

♦  For  all  listed  hazards,  the  highest  numerical  level  of  risk  is  648.  In  our  ex¬ 
ample,  the  risk  level  is  278,  which  indicates  that  a  significant  amount  of 
planning  needs  to  occur. 


Table  C-1.  Vulnerability  Analysis  Chart — Example 


Type  of 
emergency 

Probability 
(0  =  low,  5  =  high) 

Impacts 

(0  =  low,  5  =  high) 

Capability 

(1  =  best,  5  =  worst) 

Risk 

Human 

Property 

Business 

Internal 

resources 

External 

resources 

Total 

0  to  30 

Chemical 

2 

5 

5 

5 

2 

1 

20 

Dam  failure 

4 

5 

4 

5 

2 

1 

21 

Earthquake 

2 

5 

4 

5 

2 

1 

19 

Fire  or  wildfire 

0 

0 

0 

0 

0 

0 

0 

Flood 

3 

5 

5 

5 

2 

1 

21 

Hazardous  material 

5 

5 

5 

5 

3 

1 

24 

Heat 

4 

4 

3 

2 

2 

4 

16 

Hurricane 

3 

5 

5 

5 

4 

4 

26 

Landslide 

0 

0 

0 

0 

0 

0 

0 

Nuclear  power 
plant  emergency 

0 

0 

0 

0 

0 

0 

0 

Terrorism 

1 

5 

5 

5 

4 

3 

23 

Thunderstorm 

5 

2 

4 

3 

3 

4 

21 

Tornado 

5 

5 

5 

5 

4 

4 

28 

Tsunami 

0 

0 

0 

0 

0 

0 

0 
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Table  C-1.  Vulnerability  Analysis  Chart — Example 


Type  of 
emergency 

Probability 
(0  =  low,  5  =  high) 

Impacts 

(0  =  low,  5  =  high) 

Capability 

(1  =  best,  5  =  worst) 

Risk 

Human 

Property 

Business 

Internal 

resources 

External 

resources 

Total 
Oto  30 

Volcano 

0 

0 

0 

0 

0 

0 

0 

Wildfire 

3 

2 

5 

3 

3 

3 

19 

Winter  storm 

2 

5 

5 

5 

2 

2 

21 

Special  events 

3 

3 

4 

4 

2 

3 

19 

Cumulative 
vulnerability 
(0  to  648) 

42 

56 

59 

57 

35 

32 

278 

When  this  process  is  applied  to  a  single  threat,  other  factors  are  taken  into  ac¬ 
count.  Some  basic  assumptions  are  made  about  the  threat  and  are  weighted  on  a 
scale  of  0  to  5  in  the  same  manner  as  in  the  vulnerability  analysis  above. 

In  the  following  two  scenarios  of  a  special  event,  a  summer  riverboat  festival, 
several  factors  are  considered.  An  empirical  weight  is  applied  to  reflect  the  juris¬ 
diction’s  population  anticipated  to  be  in  the  risk  area.  The  visitor  population  that 
might  also  be  attending  is  treated  similarly.  The  local  capabilities  are  also  factored 
in,  with  the  best  capability  being  a  1  and  the  worst  rated  as  5.  Since  weather  can 
be  a  major  factor  in  this  scenario,  a  weight  is  applied  for  that  as  well.  Any  other 
external  factors  can  also  be  included  in  the  planning  matrix.  Because  this  process 
is  used  to  motivate  adequate  planning  among  potential  responders,  it  is  a  simple 
method  for  reflecting  relative  risk  and  planning  for  an  appropriate  emergency  re¬ 
sponse  if  needed. 

The  following  are  the  basic  assumptions  for  the  first  scenario: 

♦  A  summer  riverboat  festival  is  to  be  held  in  July. 

♦  The  total  community  population  is  60,000,  with  30  percent  of  the  popula¬ 
tion  expected  to  be  in  the  risk  area. 

♦  The  anticipated  visitor  population  is  5,000,  raising  the  population  at  risk  to 
23,000. 

♦  The  weather  will  be  typical  for  that  area  at  that  time,  so  it  is  given  a  low 
weight. 

♦  The  primary  external  factor  will  be  the  number  of  boats  on  the  river  during 
the  event,  which  could  raise  the  level  of  risk. 

♦  Internal  and  external  resources  necessary  for  these  various  factors  are 
weighted. 
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Use  of  the  Vulnerability  Analysis  Chart 


Table  C-2  shows  the  results. 


Table  C-2.  Special  Event — Scenario  1 


Factors 

Local  estimates 
(0  =  low;  5  =  high) 

Impacts 

(0  =  low;  5  =  high) 

Capability 

(1  =  best;  5  =  worst) 

Risk 

Human 

Property 

Business 

Internal 

resources 

External 

resources 

Total 
Oto  30 

Community  population 
in  risk  area 
(0  [low]  to  5  [high]) 

3 

3 

1 

1 

3 

4 

15 

Visitor  population  in 
risk  area 

(0  [low]  to  5  [high]) 

2 

3 

1 

0 

3 

4 

13 

Weather 

(0  [mild]  to  5  [life 

threatening]) 

2 

3 

1 

1 

3 

1 

11 

External  factors 
(1  [best]  to  5  [worst]) 

4 

4 

4 

2 

5 

5 

24 

Cumulative 
vulnerability 
(0  to  120) 

11 

13 

7 

4 

14 

14 

63 

The  second  example  illustrates  a  different  scenario  using  the  community  popula¬ 
tion  factor  but  different  conditions.  The  basic  assumptions  for  the  second  scenario 
are  as  follows: 

♦  A  summer  riverboat  festival  is  to  be  held  in  July. 

♦  The  total  community  population  is  60,000,  with  30  percent  of  the  popula¬ 
tion  expected  to  be  in  the  risk  area. 

♦  The  anticipated  visitor  population  is  20,000,  raising  the  population  at  risk 
to  38,000. 

♦  The  weather  will  be  hotter  than  usual  for  that  area  at  that  time,  so  it  is 
given  a  higher  weight. 

♦  The  primary  external  factor  will  be  the  number  of  boats  on  the  river  during 
the  event,  which  could  raise  the  level  of  risk. 

♦  Internal  and  external  resources  necessary  for  these  various  factors  are 
weighted  in  relation  to  their  ability  to  respond  given  these  conditions. 

Table  C-3  shows  the  results.  As  one  would  expect,  the  second  scenario  has  a 
higher  the  risk — 88  out  of  a  possible  120,  compared  to  63  for  the  first  scenario. 
This  result  indicates  the  need  for  cooperation  among  local  emergency  service 
agencies  to  plan  and  arrange  for  outside  resources  to  be  on  standby  to  assist  as 
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necessary.  The  process  can  be  as  simple  or  as  complex  as  necessary  to  ensure  ade¬ 
quate  planning  and  mitigation. 

Table  C-3.  Special  Event — Scenario  2 


Factors 

Local 
estimates 
(0  =low, 

5  =  high) 

Impacts 

(0  =  low,  5  =  high) 

Capability 

(1  =  best,  5  =  worst) 

Risk 

Human 

Property 

Business 

Internal 

resources 

External 

resources 

Total 

0  to  30 

Community  population  in  risk 
area 

(0  [low]  to  5  [high]) 

3 

3 

1 

1 

3 

5 

16 

Visitor  population  in  risk  area 
(0  [low]  to  5  [high]) 

5 

5 

2 

3 

4 

5 

24 

Weather 

(0  [mild]  to  5  [life  threatening]) 

3 

5 

1 

1 

4 

5 

19 

External  factors 
(1  [best]  to  5  [worst]) 

5 

5 

5 

4 

5 

5 

29 

Cumulative  vulnerability 
(0  to  120) 

16 

18 

9 

9 

16 

20 

88 
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Appendix  D 

Operational  Requirements 


This  appendix  lists,  in  Table  D-l,  the  operational  requirements  identified  by  our 
interviewees.  The  requirements  are  grouped  into  the  following  categories: 

♦  Coordination 

♦  Culture 

♦  Education  and  training 

♦  Funding 

♦  Information 

♦  Interoperability 

♦  Policy 

♦  Processes 

♦  Standards. 


Table  D-1.  Operational  Requirements 


Category 

Functional  requirement 

Coordination 

Jurisdictions  would  like  a  tool  to  track  donations. 

Jurisdictions  would  like  a  tool  to  track  requests  for  assistance. 

Jurisdictions  would  like  a  tool  that  tracks  responders  within  buildings  (underground?). 

Jurisdictions  need  a  way  to  track  expenditures  for  public  works  departments. 

All  disciplines  at  the  table  for  planning,  information  sharing. 

Routine  monthly  in-house  training. 

Cooperative  agreements  with  community  colleges  to  waive  fees  for  classes  for  public  safety 
personnel. 

Culture 

Use  of  non-emergency  event  management  software  and  modeling  leads  to  proficiency  in  the 
use  of  these  tools  for  emergencies  (daily,  etc.). 

Seeking  input  from  groups  with  unique  expertise  and  resources  for  dealing  with  special  popu¬ 
lations. 

Larger  jurisdictions  encourage  virtual  participation  of  smaller  jurisdictions  in  the  daily  use  of 
EOC  software  to  share  perspectives  on  planning  and  response  requirements. 
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Table  D-1.  Operational  Requirements 


Education  and  Jurisdictions  need  scenario-based  training  with  simulation  and  virtual  reality  that  includes  role 
training  playing  and  is  fully  computer  based. 


Jurisdictions  need  to  be  able  to  train  together  to  prepare  for  situations  involving  interstate  re¬ 
sponse  to  large  disasters. 

Jurisdictions  need  to  coordinate  emergency  management  training/education  through  local 
community  colleges;  waive  all  class  fees  for  public  safety. 

Jurisdictions  need  processes  that  will  help  identify  functions  that  jurisdictions  need  to  perform 
better,  and  incorporate  software  that  will  best  meet  their  functional  requirements. 

Cross-training  of  all  response  personnel. 

A  mentoring  program  for  knowledge  transfer  to  relevant  EM  employees  to  deal  with  attrition 
(brain  drain)  through  retirement  and  career  change. 

Funding  Jurisdictions  need  grants  to  cover  IT  personnel,  software  maintenance,  and  other  software  life- 

cycle  costs. 

Jurisdictions  need  grants  to  cover  ongoing  training. 

Jurisdictions  need  grants  to  cover  routine  exercises. 

Jurisdictions  need  grants  to  cover  scheduling  tools/software. 

Jurisdictions  need  grants  to  cover  command  and  control  technology  for  tracking  vehicles  and 
personnel. 

Jurisdictions  need  grants  to  cover  HazMat  PPE,  as  well  as  training  and  maintenance. 
Jurisdictions  need  grants  to  cover  satellite  communications  that  would  ensure  redundancy. 
Jurisdictions  need  grants  to  cover  MDTs. 

Federal  funding  is  either  not  provided  or  not  sustained  for  acquisition,  training,  operation,  or 
maintenance  of  software/systems  that  are  programmatically  mandated  or  if  there  is  an  implied 
mandate  when  acquisition  eligibility  is  federally  authorized. 

The  perspective  of  many  local  jurisdictions  is  that  tools  for  managing  the  grants  process  don’t 
provide  for  the  frequent  changes  in  federal  policy  and  regulations  which  results  in  unantici¬ 
pated  and  undue  burdens  on  local  jurisdictions. 

Information  Jurisdictions  need  real-time  information  regarding  event  conditions. 

Jurisdictions  need  databases  of  their  own  resources  and  resources  available  to  them  outside 
their  jurisdiction. 

There  is  a  lack  of  access  by  local  EMAs  to  continuous  critical  data,  such  as  weather  informa¬ 
tion,  that  would  assist  them  with  planning  and  responding  effectively. 

Jurisdictions  would  like  to  have  regular  notifications  and  alerts  from  forestry  agencies  and  ac¬ 
cess  to  details  about  any  forestry-related  events,  with  drill-down  to  detail. 

Jurisdictions  need  tools  and/or  models  to  work  for  everyday  operations  and  to  scale  up  or 
down  to  support  the  size  of  the  incident. 

Jurisdictions  would  like  a  nationwide  credentialing  system  to  track  KSAs. 

Jurisdictions  would  like  tools  that  enable  barcode  and  scanner-enabled  material  management. 
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Operational  Requirements 


Table  D-1.  Operational  Requirements 


Information  Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  to  the  public. 


Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  both  static  and 
dynamic/real-time  to  the  public. 

Jurisdictions  would  like  tools  that  will  enable  them  to  disseminate  information  to  special  popu¬ 
lations,  and  also  an  application  (maybe  self-service)  to  let  special-needs  populations  (non- 
English  speakers,  mobility-impaired  people,  etc.)  voluntarily  register. 

Tools  that  have  asset  tracking  capabilities  need  resource  tracking,  including  “typing”  according 
to  DHS  requirements.  (Would  like  an  online  place  so  they  could  put  up  checklists.) 

Tools  that  have  asset  tracking  capabilities  need  to  perform  asset  visibility  and  tracking:  people 
and  other  resources. 

Tools  that  have  asset  tracking  capabilities  need  to  provide  the  capability  to  exchange  ware¬ 
house  information  on  available  resources. 

Jurisdictions  need  real-time  dependable  asset  accountability  system  (related  to  asset  track¬ 
ing). 

Jurisdictions  would  like  a  web-based  system  for  tracking  volunteers-interactive  for  the  volun¬ 
teer  to  enter  data;  a  self-service  application. 

Jurisdictions  need  tools  that  provide  locations  for  points  of  distribution  (for  resources,  sup¬ 
plies);  a  tool  to  better  manage  regional  response  assets. 

Jurisdictions  would  like  a  tool  that  has  information  needed  for  planning,  such  as  certain  types 
of  addresses  and  occupancies. 

Jurisdictions  would  like  a  tool  that  provides  state-wide  GIS  capabilities  (such  as  “Virtual  Ala¬ 
bama”)  and  contains  information  on  who  owns  the  land  and  populated  areas,  as  well  as  prop¬ 
erty-line  information. 

Jurisdictions  would  like  to  have  a  tool  that  can  capture  specific  information  about  events,  which 
can  then  be  shared  among  response  agencies,  providing  a  central  repository  for  information 
about  any  event. 

Jurisdictions  need  WebEOC  to  exchange  information  and  have  compatibility  between  ver¬ 
sions. 

Jurisdictions  need  tools  and  models  to  integrate  data  capture  and  use  for  exercise  simulation 
and  documentation. 

Jurisdictions  require  data  that  are  easy  to  integrate  on  simulated  maps  (Virtual  Alabama  is  an 
example  of  this). 

Jurisdictions  need  storm  surge  data  that  can  be  overlaid  on  flood-zone  maps  and  then  inte¬ 
grated  with  reverse  91 1  information. 

Jurisdictions  would  like  a  clearinghouse  for  EM  data:  casualties  under  scenarios,  etc. 

Jurisdictions  need  a  tool  that  will  capture  information  from  the  Pacific  Disaster  Warning  Center/ 
Pacific  Tsunami  Warning  Center,  NOAA,  universities,  U.S.  Forest  Service,  State  Forestry, 
Weather  Service,  etc. 

Communication  and  sharing  of  information  with  communities  of  similar  size  and  resources  in 
order  to  stay  abreast  of  best  management  practices. 

Publish  self-help  information  in  Phonebooks  for  visitors  and  residents  for  personal  planning 
and  response  to  potential  local  emergency  threats. 
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Table  D-1.  Operational  Requirements 


Interoperability  Tools  that  have  asset  tracking  capabilities  need  to  be  consistent  with  DHS/NIMS  and 
WebEOC. 

Tools  that  have  asset  tracking  capabilities  need  logistics  and  resource  management  capability 


Jurisdictions  need  EOCs  to  see  what  another  EOC  in  its  jurisdiction/county/state/region  is  see¬ 
ing,  for  example,  real-time  visual  links,  data  uploads/downloads,  and  video  streaming. 

Tools  need  to  be  developed  using  a  flexible,  open  architecture  to  work  across  systems  and 
hardware. 

Jurisdictions  need  to  integrate  plume  data  in  CAMEO  with  the  GIS  and  reverse  91 1 . 
Jurisdictions  need  to  integrate  facility  plans  for  buildings  with  GIS. 

Jurisdictions  would  like  the  capability  to  integrate  surveillance  and  command/control  functions 
into  a  single  portal  for  pandemic  flu. 

Retain  “historical”  data  for  specific  response  activities  to  use  in  estimating  future  response 
needs. 

Use  of  video  streaming  capability  that  contributes  to  interoperability. 

Policy  Availability  of  funds  determines  how  often,  or  if,  plans  can  be  exercised. 

Federal,  state,  and  local  funds  are  limited  and  do  not  cover  full  participation  in  exercises. 

There  is  a  lack  of  technical  personnel  for  IT  dedicated  positions  who  also  understand  and  are 
able  to  support  specific  emergency  management  issues. 

Jurisdictions  need  a  policy  on  how  to  mitigate  limiting  factors  (managing  software  once  we  get 
it,  sustainment,  staff  or  money). 

Processes  Some  areas  have  limited  training  and  restricted  access  to  control  data  entry  to  ARC  GIS 
maps. 

Identification  of  the  technology  functions  that  a  jurisdiction  needs  to  function  more  effectively 
and  efficiently. 

Jurisdictions  would  like  a  process  to  evaluate  software  that  will  best  meet  their  functional  re¬ 
quirements. 

Jurisdictions  would  like  a  tool  that  provides  inventory  management  capabilities. 

Jurisdictions  need  to  perform  risk  management  (risk  identification,  assessment,  risk  prioritiza¬ 
tion  and  response  planning,  and  risk  monitoring).  This  will  enable  them  to  model  low-risk  and 
high-impact  situations.  They  would  like  simple  models  for  risk,  to  apply  mitigation  strategies  as 
appropriate. 

Jurisdictions  would  like  to  have  tools  to  estimate  resource  requirements. 

Jurisdictions  need  tools  for  expedient  evaluation  of  event  results. 

Jurisdictions  need  tools  for  evacuation  modeling. 

Jurisdictions  would  like  templates  for  memorandums  of  understanding  so  that  they  can  facili¬ 
tate  getting  these  with  the  appropriate  groups. 

Jurisdictions  would  like  tools  to  let  special-needs  populations  (non-English  speakers,  mobility- 
impaired  people,  etc.)  voluntarily  register. 

Jurisdictions  need  tools  for  planning  and  managing  mass  casualty  events. 

Jurisdictions  would  like  the  ability  to  identify  response  capabilities  and  resource  location. 

Jurisdictions  would  like  a  tool  that  provides  a  live  feed  into  emergency  dispatch  center  with 
POCs  for  each  location  in  an  event. 
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Operational  Requirements 


Table  D-1.  Operational  Requirements 


Jurisdictions  need  flu  surveillance  and  command  and  control 


A  tool  to  tie  in  information  and  form  data  between  the  local  emergency  management  people, 
FEMA,  the  localities,  and  the  state  (while  also  taking  into  account  the  budget,  funding,  thresh¬ 
olds,  etc.),  and  then  navigate  the  bureaucratic  paperwork  and  workflow. 

Jurisdictions  need  R&D  regarding  processes  and  cross-agency  boundaries  for  funding 
mechanisms. 

Jurisdictions  would  like  a  central  repository  to  document  exercises  and  simulations  based  on 
information  in  other  systems  such  as  WebEOC  and  to  capture  and  retrieve  After  Action  Re¬ 
ports  and  lessons  learned  documentation. 

Jurisdictions  need  a  process  to  handle  maintenance  costs,  which  are  a  major  factor  in  estab¬ 
lishing  a  system.  They  do  not  have  in-house  capability  to  handle  management  and  mainte¬ 
nance  of  the  systems  and  cannot  afford  to  get  it. 

Jurisdictions  need  processes  for  using  large  events  to  put  plans  into  action  more  frequently. 

Jurisdictions  need  processes  to  produce  an  interoperable  system  across  IT  departments  as 
well  as  EOCs. 

Jurisdictions  need  to  learn  about  software/IT  and  the  SDLC  and  to  become  familiar  or  get  this 
expertise  to  do  a  “minimal”  job  themselves. 

Tools  to  support  a  process  to  capture  lessons  learned  with  a  closed  loop  change  process. 

Inclusion  of  representatives  from  special-population  facilities  (such  as  prisons,  institutions, 
etc.)  to  participate  in  a  community-wide  planning  effort  for  response. 

Standards  FEMA  regions  fail  to  support  and  standardize  on  either  specific  software  applications  (for  ex¬ 
ample,  WebEOC)  or  on  critical  data  exchange  functions  commonly  in  use  throughout  their  re¬ 
gion. 
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Appendix  E 

Abbreviations 


COP 

DHS 

EM 

EMA 

EMCAPS 

EOC 

ES 

FEMA 

GIS 

IT 

LAN 

MNS 

MOU 

NGO 

NIC 

NPS 

OASIS 

S&T 

SDLC 

SWOT 

UASI 


common  operating  picture 

Department  of  Homeland  Security 

emergency  management 

emergency  management  agency 

Electronic  Mass  Casualty  Assessment  and  Planning 
Scenarios 

emergency  operations  center 
emergency  services 

Federal  Emergency  Management  Agency 
geographic  information  system 
information  technology 
local  area  network 
mission  needs  statement 
memorandum  of  understanding 
non-governmental  organization 
National  Integration  Center 
National  Planning  Scenario 

Organization  for  the  Advancement  of  Structured  Informa¬ 
tion  Standards 

Directorate  for  Science  and  Technology 
software  development  life  cycle 
strengths,  weaknesses,  opportunities,  and  threats 
Urban  Area  Security  Initiative 
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